RedHat Enterprise Satellite server deployment guide...
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
Chapter 1. Essential System Management
Tools: Bash, Perl, and Ruby are all scripting languages that may be used in the %post section of a kickstart file. sed is the streaming editor that is useful for making changes to existing files as well as editing the output from other programs. In the %post section of a kickstart file, all scripts run in a chroot'ed environment by default, allowing you to easily use any interpreter installed on the new system. With the wide variety of tools included in Red Hat Enterprise Linux, there is virtually no limit to what may be automatically performed for system installation or management.
The "One-off" Trap One-off systems require special care and extra work to maintain. Generally the longer they are kept running the worse of a headache they become. Unique Installations: Every uniquely installed system requires extra work to maintain. Avoid unique installations. Package Management: Ideally, package management should be pervasive. Every piece of software install outside of package management will require more work and at the same time be less visible as a potential problem. Configuration Files: The use of a version control system to maintain configuration files, combined with a centralized system to manage them allows for quick and efficient deployment as well as rollbacks, when needed. Documentation: Everything should be documented. This includes software versions, baseline definitions, configuration files, and procedures.
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
Chapter 1. Essential System Management
PXE/Kickstart Installation PXE Peer Tutoring Your instructor will split the class into teams. Gather around one of your machines and determine how to initiate a PXE installation. Write the steps needed to PXE boot below.
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
Chapter 1. Essential System Management
Test
Criterion Test Exercise
Provisioning Preview Before you begin... You have two servers: desktopX and desktopY. Both servers are currently connected to the classroom network (192.168.0.0/24) which includes the instructor's machine, instructor.example.com. desktopX should be equipped with two Ethernet interfaces. Carefully perform the following steps. Ask your instructor if you have problems or questions. Let's preview the capabilities and conveniences of a bare-metal provisioning environment. The instructor's machine, instructor.example.com, has been configured to provide bare-metal provisioning services. Your task is to configure both of your servers to PXE-boot and kickstart themselves. 1.
Reboot desktopX and go into the system BIOS configuration screens and make adjustments so desktopX will attempt to PXE boot from the network. Ask your instructor for help since this process can vary between various classroom environments.
2.
Reboot desktopX, but this time allow it to PXE boot from the network. If everything is properly configured, you should be presented with a PXE boot menu similar to the following:
Choose the “Install minimal RHEL 5 for RHN Satellite use” option without any arguments to begin the installation. While the installation begins, repeat these steps on your second
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
Chapter 1. Essential System Management
Personal Notes
10
RH401-6-en-1-20110713
Centralization
Unit Summary Enterprise Management Best Practices In this section you learned the value of: • Standardization • Centralization • Scalability • Provisioning • Automation . PXE/Kickstart Installation In this section you learned how to: • Initiate a PXE installation • Determine kickstart arguments in an installation .
RH401-6-en-1-20110713
11
12
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
Chapter 2. Installing a Red Hat Network Satellite Server
RHN Satellite Server Installation Standalone vs. Embedded Database The RHN Satellite Server requires a database. If you already have an Oracle database with sufficient disk space and power, you can use it to hold the RHN Satellite Server database provided that you have a database administrator who can manage the setup of the service. It is important you do not run the RHN Satellite Server on the same system that runs the Oracle database. If you do not have an Oracle database, or if it does not have sufficient disk, RAM, or CPU resources, you can install the RHN Satellite Server with an embedded database. This database requires additional disk space. It has the advantage of having a single system acting as both Satellite Server and database server. Further, the database is already fully configured, requiring less effort on the part of the database administrator.
Hardware Requirements RHN Satellite Servers have relatively high hardware requirements since they can run an instance of the Oracle database (for the embedded version) as well as deliver a large amount of data to remote systems. Because the Oracle database runs multiple processes, multiple processors can significantly improve performance. The RHN Satellite Server uses a considerable amount of disk space and it is time consuming to repopulate a database should a disk fail. It is strongly recommended to use redundant storage to hold the underlying data. The hardware specifications outlined in the Red Hat Network Satellite Installation Guide are standard minimal and recommended specifications for Red Hat Network Satellite. The following table shows typical specifications and capacity of RHN Satellite server deployments: Hardware specifications
RHN client system capacity
32-bit x86 with 2GB of RAM
~500 RHN client systems
32-bit x86 with 4GB of RAM
~2,000 RHN client systems
64-bit x86 with 8-16GB of RAM
~15,000 RHN client systems
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
Chapter 2. Installing a Red Hat Network Satellite Server
SSL certificate information: All communication between your Satellite Server and its clients will be done through encrypted tunnels. This requires an SSL certificate. You will have to provide information about your organization, its location, and a certificate password which you should record and put in a safe place. This is a long process, typically taking near an hour to complete, including the time needed to answer the installer's questions and for the computer to process the data. Installer log messages can be found in a file called /var/log/rhn/rhn-installation.log.
install.pl Options Options can be passed to install.pl to modify how it behaves when installing the Satellite Server software. The --disconnected option indicates the Satellite Server will operate disconnected from the Internet. In this case install.pl will not prompt for RHN credentials used to connect to Red Hat's servers. An answer file can be specified at install time with the --answer-file option. The user provides install.pl with the absolute path name to a text file with answers to the installer's questions which the user created beforehand. This allows the installation process to be performed in an unattended manner which prevents mistakes from being committed during the installation process. A sample answers.txt file can be found on the Satellite Server install media in the install subdirectory.
Note The --answer-file option requires an absolute path name. When a relative path name is specified, the RHN Satellite installer will silently ignore this option and start prompting the user with questions.
The --re-register option causes install.pl to re-register the Satellite Server with Red Hat Network, even if it is already registered. --clear-db tells install.pl to clear any existing database schema before installing on a previously installed server. This is useful when Satellite Server software needs to be reinstalled. A best practice is to install a RHN Satellite Server in disconnected mode and initially populate it from local media. The eliminates any dependence upon Internet connectivity and grants best installation performance. Later the Satellite Server can be registered and reactivated with Red Hat Network, then channel content can be brought up to date against Red Hat's servers.
References Red Hat Network Satellite Installation Guide • Chapter 2: Requirements • Chapter 4: Installation
18
RH401-6-en-1-20110713
Installing Satellite Server: The Base Install
Practice Performance Checklist
Installing Red Hat Network Satellite Software Before you begin... You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopX. Install RHN Satellite software on your provisioning server, desktopX. Copy the sample RHN Entitlement Certificate, redhat-gls-minimal-5.4.cert, from the instructor's machine to root's home directory (~). This file can be found in the automounted /misc/instructor/rh401-satellite directory. Copy the satellite-embedded-*.iso image found on the instructor's machine to / tmp then mount it using a loopback device to /mnt. Don't execute /mnt/install.pl. We will use this script shortly. Instead list the contents of /mnt/install and look for a file called answers.txt. This file can be modified and used with install.pl to perform an unattended installation of the RHN Satellite Server software. Copy answers.txt to root's home directory. Use your favorite text editor to modify root's answers.txt file. Find the following variable definitions and make all necessary adjustments: # RHN Satellite Server administrator admin-email =
[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
Chapter 2. Installing a Red Hat Network Satellite Server
Once the SSL certificate has been generated and imported into the Satellite Server, install.pl will restart the Satellite Server then exit. A URI will be displayed which you can use with a browser to complete the installation process. Launch a web browser and visit the URI displayed by install.pl: https:// desktopX.example.com. Examine the certificate offered to your browser and see if you recognize some of the values about the certificate subject and the issuer. Once you are satisfied with the contents of the certificate, accept it into your browser permanently. Create a RHN user called satadmin with a password of redhat. The e-mail address for this account should be
[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
Chapter 2. Installing a Red Hat Network Satellite Server
Note Importing channel content into a RHN Satellite server can take a long time to complete. This is especially true when a Satellite server is freshly installed. Installing a small base channel and restarting the Satellite server causes the embedded database to initialize itself so that further channel installs are much quicker. In the lab exercise, a simple base channel called one-rpm-channel will be used for this purpose.
Using Channel ISOs to Populate the Satellite Server To populate the database using the Channel Content ISOs: 1.
Confirm you have sufficient disk space. You will need disk space for the ISOs and the data to be extracted from the ISOs, in addition to the disk space needed to store the data in the database.
2.
Download the Channel Content ISOs from Red Hat Network. • Log onto Red Hat Network and click the Software Downloads icon. • Expand the base channel called Red Hat Enterprise Linux (v. 5 for 64-bit x86_64), or the version of Red Hat Enterprise Linux you are using, by clicking the plus symbol to the left of the channel name. Then click the link for the latest Red Hat Network Satellite channel. For example, you might select Red Hat Network Satellite (v5.4 for Server v5 AMD64 / Intel64). • Click View Base Channel Content ISOs for Satellite to list the Channel Content ISOs. Scroll down to find the Channel Content ISOs for the channel you wish to download. For example, scroll down to Red Hat Enterprise Linux 5 Client/Server (i386) + rhn-tools + vt + cluster + supplementary + workstation (Base 2009-09-30) to download the content ISOs for that channel.
3.
For each channel, mount each ISO in turn and copy the data to a temporary directory. If you intend to use the expanded channel content on more than one Satellite Server (or back it up), be sure to mount it read only since satellite-sync will attempt to remove the content as it imports the RPMS.
4. List the channels available from the Channel Content ISOs. For example, if you have copied the ISO data into a directory called /rhn-sat-import, then list the available channels by running: [root@host ~]# satellite-sync -m /rhn-sat-import --list-channels
5.
Run the satellite-sync command to upload the information from this directory into the Satellite Server. For example, to load the rhel-i386-server-5 channel into the database that has been copied into /rhn-sat-import, run: [root@host ~]# satellite-sync -m /rhn-sat-import -c rhel-i386-server-5
22
RH401-6-en-1-20110713
Using Channel ISOs to Populate the Satellite Server
Installing a base channel does not include the child channels or the related channels. They must be installed separately.
References Red Hat Network Satellite Installation Guide • Chapter 7: Troubleshooting
RH401-6-en-1-20110713
23
Chapter 2. Installing a Red Hat Network Satellite Server
Practice Performance Checklist
Preparing Channel Content for Import Before you begin... The RHN Satellite software installation on your desktopX machine should be completed. Channel content ISOs are available from the instructor's machine, instructor.example.com. Extract their contents into a common directory on your Satellite server, desktopX, so the channel content can be imported in a later lab exercise. The first step to take is make sure you have enough disk space to extract the content ISOs. They will require over 8 GB of space. Notify your instructor if you don't have enough room on your machine to extract them. The content ISOs are published to the classroom in the /misc/instructor/rh401satellite/sat-rhel6-content/ directory. Mount the content ISOs using a loop interface to /mnt and copy the contents of both ISOs to a directory called /root/satrhel6-content/.
24
RH401-6-en-1-20110713
Importing Initial Software Packages
Importing Initial Software Packages RHN Software Channels The Red Hat Network system deploys packages based on the concept of software channels. A software channel is essentially a collection of packages. The two types of software channels are base channels and child channels. A base channel is the collection of packages that all systems using a particular type of software typically will install (it is not always necessary to install all packages, but a full install would include all of these packages). Child channels provide additional software related to the base channel. For example, if you browse Red Hat Network's Channels tab, you will see the latest version of the Red Hat Enterprise Linux base channel along with its associated child channels. It will look something like this: Channel Red Hat Red Hat Red Hat Red Hat Red Hat Red Hat
Name Enterprise Linux Server 5 FasTrack Server 5 Network Tools Server 5 Productivity Apps Server 5 Supplementary Server 5 Virtualization Server 5
Architecture IA-32, IA-64, IA-32, IA-64, IA-32, IA-64, IA-32, x86_64 IA-32, IA-64, IA-32, IA-64,
PPC, s390x, x86_64 PPC, s390x, x86_64 x86_64 PPC, s390x, x86_64 x86_64
The channels are listed in alphabetical order by name, followed by the architectures relevant to that channel. The channel listing on a Satellite Server looks a little different. The software channels are displayed in a way that shows their relationship to each other. The base channel is displayed first with its child channels appearing immediately below their parent:
Channel Name -Red Hat Enterprise Linux (v. 5 for 32-bit x86) |--RHEL Virtualization (v. 5 for 32-bit x86) ...
Packages 3239 67
Systems 10 3
RHN Entitlement Certificate Entitlement Certificates unlock the services of Satellite Servers. They define how many systems can register with the Satellite Server and what types of system entitlements they have, such as Update, Management, Provisioning, or Monitoring. They also define the number and type of software channels that can be subscribed to. An Entitlement Certificate can limit which menus appear on the RHN Web Interface of a Satellite Server. For example a Satellite Server without Provisioning system slots won't present the Kickstart menu or features that apply only to systems with Provisioning entitlements. RHN Satellite Entitlement Certificates are issued and digitally signed by Red Hat so they can't be tampered with. Below is a portion of a sample certificate: RHN-SATELLITE-001 Red Hat GLS Cert
RH401-6-en-1-20110713
25
Chapter 2. Installing a Red Hat Network Satellite Server
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
Chapter 2. Installing a Red Hat Network Satellite Server
Practice Performance Checklist
Populating RHN Satellite with RHEL6 Software Before you begin... The RHN Satellite software installation on your desktopX machine should be completed and RHN channel content from both ISOs should be expanded into the /root/sat-rhel6-content/ directory on that server. Import the RHN base channel content for the Red Hat Enterprise Linux 6 Server software for 64bit x86 machines into your RHN Satellite server. The first software channel to be imported into a RHN Satellite 5.4 server takes much more time to import that subsequent channels. To conserve time, import the onerpm-channel base software channel published in the /misc/instructor/rh401satellite/one-rpm-channel.tar tar archive. Change into root's home directory on desktopX, extract the archive, import the one-rpm-channel software channel, then reboot your Satellite server before importing the Red Hat software channels. Log back into desktopX as root. The sat-rhel6-content directory below root's home directory contains the software channel content needed to deploy Red Hat Enterprise Linux 6 Server. Before you populate the database with RPMs and other information for a particular channel you must first find out which channels are available. Which software channels are provided by the content in the sat-rhel6-content directory? Now that you have determined which channels are available, import the rhel-x86_64server-6 channel data from the sat-rhel6-content directory into your Satellite Server's database. This process takes a very long time to complete. Use a web browser to browse https://desktopX.example.com, where X is the machine number of your Satellite Server. You probably want to bookmark this page since you will refer to it often in upcoming lab exercises. Log in as the Satellite Administrator, satadmin. Navigate around the web site, particularly looking at the Errata, Channels, Users, and Admin tabs. Your RHN Satellite Server is now installed and will be ready to be used by clients when the channel content sync is complete. In a later lab you will configure clients to use this server.
28
RH401-6-en-1-20110713
Criterion Test
Test
Criterion Test Case Study
Deploying a RHN Satellite Server Before you begin... You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopY. Your department deploys and manages several servers running Red Hat Enterprise Linux. Your facility is an extremely secure site so you don't have access to hosted Red Hat Network services via the Internet. Your manager has invested in a Red Hat Network Satellite software to manage your systems. Your task is to install the RHN Satellite software on your desktopY machine and load it with the software channels needed to deploy Red Hat Enterprise Linux 6 Server systems. All of the material you need to install the system can be found in the /misc/instructor/rh401satellite directory. Use the redhat-gls-minimal-5.4.cert RHN Entitlement Certificate to activate the server. When you install the Satellite server, make sure the SSL CA certificate information is specified as follows: • Organization = Red Hat Inc. • Organization Unit = Training • City = your city • State = your state • Country = your two-letter country code Also specify
[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
Chapter 2. Installing a Red Hat Network Satellite Server
Personal Notes
30
RH401-6-en-1-20110713
Criterion Test
Unit Summary RHN Satellite Server Concepts In this section you learned about the features, benefits, and components of Red Hat Network Satellite software. . RHN Satellite Server Installation In this section you learned how to: • Install Red Hat Network Satellite Server software . Obtaining Software from Hosted RHN In this section you learned how to: • Get RHN software channel content from Red Hat • Prepare channel content ISOs for use with RHN Satellite . Importing Initial Software Packages In this section you learned how to: • Import Red Hat software content into a Satellite server .
RH401-6-en-1-20110713
31
32
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
Chapter 3. Red Hat Network Organization
RHN User Administration Red Hat Network Users and Roles User accounts are managed by the Organization Administrator within each organization. User names (login) must be at least 5 characters in length and must be unique across the Satellite Server. For example there can't be two users named “wayne” even though they belong to two different organizations. To create a user, login as an Organization Administrator and select the Users tab. Click create new user link and assign the user a unique login name, a password, and fill in other pertinent information about the user's identity. Once the Create Login button is clicked, the account is created and appears in the list of organization users. On the Details tab of the user's page, check boxes can be selected for the roles in which they will serve. The following outline lists the different Red Hat Network roles that can be assigned to a RHN Satellite user: • Satellite administrative roles • Satellite Administrator • Organization Administrator • Other individual roles • User/System Group User (default/baseline) • System Group Administrator • Activation Key Administrator • Channel Administrator • Configuration Administrator • Monitoring Administrator Each role's function and capabilities will be covered in more detail below.
Satellite Administrator The Satellite Administrator account manages the overall function of a Satellite Server. The unique functions provided by this role include creating and deleting organizations, establishing trusted relationships between organizations, managing Satellite-wide subscriptions and entitlements, and other global administrative functions. These functions are available under the Admin tab which only appears when the Satellite Administrator is using the system. A new Satellite entitlement certificate can be activated by the Satellite Administrator using the web interface. Periodically this function has to be performed to keep a Satellite Server functioning since each certificate issued by Red Hat has a limited life based on its expiration.
36
RH401-6-en-1-20110713
Organization Administrator
Organization Administrator The Organization Administrator can perform all functions within the scope of the organization which they manage. Typically they manage user accounts and assign them roles, although Organization Administrators can perform all of the functions that belong to all of those roles. Organizations can have multiple Organization Administrators, therefore multiple administrators don't have to use a common account and share the master “organization superuser password”. Lost or forgotten Organization Administrator passwords can be e-mailed to the e-mail account associated with their RHN account or they can be changed by another Organization Administrator within their organization. They cannot be recovered or overridden by the Satellite Administrator so it is wise to have more than one Organization Administrator for each organization as a safeguard.
System Group and Activation Key Administrators System Group Administrators can create and delete system groups. They can remove systems from their system groups and can add systems to additional groups which they control, but they cannot add systems to any of their groups if there is no initial association with at least one of the system groups they control. System Group Administrators are automatically assigned control over the groups they create. An Organization Administrator must assign unassociated systems to one of the system groups of a Group Administrator to put it under their control, but this can be automated with the use of activation keys. Activation Key Administrators create and manage activation keys that are used when registering a client system to Red Hat Network. They have the authority to associate their keys with one or more of any of the system groups within their organization. Activation Key Administrators are also able to manage any activation key within their organization, regardless of which administrator created the activation key.
Channel and Configuration Administrators Channel Administrators can create, clone, and delete software channels. They can import RPMS into and delete packages from custom software channels and assign similar privileges to other users to specific software channels. All software channels can be administered by any Channel Administrator within an organization, but other users can only administrate the particular channels assigned to them. Channel Administrators can also manage errata. Configuration Administrators serve similar functions as Channel Administrators, but they manage and control access to configuration channels instead of software channels. Administrative responsibilities for configuration channels cannot be delegated to users who aren't Configuration Administrators. Provisioning add-on entitlements must be assigned to systems before they can be considered as a target system for configuration channels.
Monitoring Administrator and Default User Monitoring Administrators can schedule probes and administrate other system monitoring functions. Although this role can be assigned to any user by an Organization Administrator, it only serves a purpose on Satellite Servers where system monitoring has been enabled by the Satellite Administrator on a Satellite-wide basis. All accounts serve as System Group Users when they aren't assigned an additional Red Hat Network administrative role. Organization Administrators can assign system groups to System
RH401-6-en-1-20110713
37
Chapter 3. Red Hat Network Organization
Group Users for administration by going to the System Groups tab within the Users tab. Channel Administrators can also grant software channel administrative privileges for specific channels to System Group Users.
References Red Hat Network Satellite Deployment Guide • Chapter 1: Users
38
RH401-6-en-1-20110713
Organization Administrator
Practice Exercise
Creating User Accounts and Assigning Roles Carefully perform the following steps. Ask your instructor if you have problems or questions. •
Log in to the Satellite server on desktopX as the Organization Administrator for the Example Inc. organization and create the following users as members of that organization: Standard user
Privileged user
Login
normal
grouper
Password
redhat
redhat
Full name
Mr. Norman Normal
Ms. Gladys Grouper
Roles
System Group User
System Group Administrator
Specify
[email protected] as the e-mail address for both RHN Satellite accounts.
RH401-6-en-1-20110713
39
Chapter 3. Red Hat Network Organization
System Groups System Groups The most important organizational unit for massive deployment is the system group. Red Hat Network can organize systems into groups allowing for a variety of configuration changes to the group as a whole, including application of new and updated packages and individual files. Red Hat Network user accounts can be given administrative access to RHN systems by group. Note that an individual system can belong to multiple system groups.
References Red Hat Network Satellite Reference Guide • Section 7.4.3: System Groups
40
RH401-6-en-1-20110713
Organization Administrator
Practice Exercise
Managing System Groups Carefully perform the following steps. Ask your instructor if you have problems or questions. 1.
Log in to the Satellite server on desktopX as the Organization Administrator for the Example Inc. organization, if necessary, and create a system group called “example servers.” Fill the group description with useful information of your choice. Do not make any security adjustments or assign administrators to the new group. Examine the initial access privileges for normal and grouper to the example servers group.
2.
Modify the example servers system group so grouper can administrate the group. Sign in as grouper and normal and observe what access they have to the system group.
3.
Log in as grouper and modify the group so normal can administer systems in that group. Log in as normal and confirm he has access to the group.
RH401-6-en-1-20110713
41
Chapter 3. Red Hat Network Organization
Personal Notes
42
RH401-6-en-1-20110713
Organization Administrator
Unit Summary RHN Organization Administration In this section you learned how to: • Create a Red Hat Network organization • Assign base and software entitlements to a RHN organization . RHN User Administration In this section you learned how to: • Create users within a RHN organization • Modify the role of a RHN user . System Groups In this section you learned how to: • Create a system group within an organization • Assign a System Group Administrator control over a system group • Assign a normal user as a system administrator within a system group .
RH401-6-en-1-20110713
43
44
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
Chapter 4. Using Subversion to Manage Changes
Subversion Administration Initializing a New Repository The svnadmin create command creates a new repository. This command must be executed by a user who has write permissions to the directory where the repository will be created. Although a user can create a private repository, most repositories are used by multiple users on a system so root usually must create and secure system-wide repositories. A simple way to set up a repository that will allow secure authentication is to allow Subversion over SSH (svn+ssh). Make sure the sshd daemon is started and is configured to start on boot. User accounts will have to be created and passwords assigned for each of the remote users who will access the repository.
Subversion Security Once a new Subversion repository is created, determine which users need read-only and readwrite access to the projects that will be added to the repository. The best way to handle this is to put all of the appropriate users into a group and make the db directory read-write and setgid for that group. When two groups of users have conflicting security requirements, create two separate repositories for their projects. [root@host ~]# groupadd -g 20000 svnuser [root@host ~]# chgrp -R svnuser $REPO_PATH [root@host ~]# chmod -R g+w $REPO_PATH/db
ACLs on ext3 filesystems can be used to restrict or allow access to a repository by additional groups or individual users.
Starting a Subversion Project Starting a project in Subversion is very simple. First, create a directory and populate it with the initial revisions of files that make up the project. Create and populate subdirectories as needed. Once you have decided on your project directory structure and created your initial content, import it into your repository. Change into the top level directory of your new directory tree and type: [user@host tmp]$ svn import $REPO_URL/newproject
Notice the name of the original directory used to organize the project and the name of the project in the repository do not have to be the same. Choose a short, but descriptive, project name so it is easy to identify it when listing a repository's contents. The svn import command will recursively search through subdirectories. Like svn commit, the import command will open the default text editor for an initial log message. Since this is the original import of a project's content, the log message should briefly describe what the project is.
Other Revision Control Software RCS is the great-grandfather of open source revision control software. It works on a single system (it doesn't have network capability) and works on the premise that users have to check
48
RH401-6-en-1-20110713
Other Revision Control Software
out locked copies of files they want to edit. The rcs RPM provides the suite of RCS tools and is supported with Red Hat Enterprise Linux. CVS (Concurrent Versions System) is a popular revision control system. Its commands are accessed using cvs followed by a subcommand then options and arguments. The CVS subcommands were based upon the RCS commands, except CVS provided functionality over a network with a central repository. Subversion was designed to function like CVS, but without some of its limitations. The cvs RPM provides the CVS revision control system for Linux and is supported by Red Hat Enterprise Linux. The info pages for CVS are much more useful than the man pages. A good reference book for CVS is also available online at the following URL: http://cvsbook.redbean.com/cvsbook.html. Another distributed revision control system is Mercurial. It provides similar functionality to Subversion, but it is invoked as hg on the command line and it has additional subcommands that Subversion doesn't provide. Mercurial is written in Python and has an integrated web interface. Red Hat Enterprise Linux does not provide Mercurial at this time, but it is provided by Fedora. git is a distributed revision control system that operates on the principle that every working directory acts as a complete repository managing complete change history. Developers use git to coordinate and facilitate Linux kernel development. Like Mercurial, git is provided by Fedora, but not Red Hat Enterprise Linux at this time.
References “Version Control with Subversion” book available on-line at http://svnbook.redbean.com svnadmin(1) man page and svnadmin help Subversion subcommand
RH401-6-en-1-20110713
49
Chapter 4. Using Subversion to Manage Changes
Practice Exercise
Preparing the Subversion Repository and Users Before you begin... In this lab one of your two machines will be referred to as desktopX and will host the Subversion repository. This machine should be your RHN Satellite Server since you will reinstall desktopY to complete later labs. Your client machine, desktopY, will serve as the remote workstation of one of your Subversion users. Make sure the clocks on both of your machines are synchronized with each other. If you need to install packages, yum should already be configured on desktopX and desktopY. Carefully perform the following steps. Ask your instructor if you have problems or questions. Your internal DNS servers have had some problems lately. The DNS administrators, Stan and Oliver, have been modifying configuration files in such a way they have been stepping on each others' changes. Your task is to deploy a Subversion server which will allow Stan and Oliver to work together and stop the configuration file conflicts. Build a Subversion repository on desktopX that will allow two users, oliver and stan, to create projects and work collaboratively. 1.
Reinstall desktopY with Red Hat Enterprise Linux 6 to prepare it for this and future lab exercises. PXE boot desktopY and select the “Install a standard RHEL 6 workstation” option.
2.
Log in as root on desktopX and install Subversion if necessary. Create a repo named /var/ local/svn on desktopX while desktopY reinstalls. After the installation finishes, check if Subversion is installed on desktopY. If not, then install it on desktopY also.
3.
On desktopX, create a group called svnuser with a group ID of 60000. Modify the Subversion repository so all users in that group can create and modify projects.
4.
Create user accounts for oliver and stan on both workstations. Assign their accounts the password of password on both systems. Make all necessary adjustments to their accounts to allow them to use Subversion from either host. Both users should be able to commit their changes to the Subversion repository without typing a password when they are logged into desktopY.
50
RH401-6-en-1-20110713
Other Revision Control Software
Practice Exercise
Starting a New Project in Subversion Carefully perform the following steps. Ask your instructor if you have problems or questions. Set up a new project in the Subversion repository for DNS configuration files. 1.
Log in as oliver on desktopX and create a subdirectory in Oliver's home directory called source. Create etc and var/named subdirectories below ~/source to provide a temporary DNS chroot hierarchy.
2.
Use anonymous FTP to download all the files in /pub/materials/namedfiles from instructor.example.com into ~/source. Move the files into the appropriate directories in the temporary tree. Do not change their names at this time.
3.
Have oliver create a new project called dnsfiles in the Subversion repository. The project should initially be populated with the files from his ~/source directory. If the group ownership and permissions assigned to the repository are correct, Oliver should be able to create the project since he is a member of the svnuser group.
4.
Confirm the files are safely in the repository. Check the dnsfiles project out from the Subversion repository on desktopX and compare its contents with the files in ~/source.
5.
Remove the ~/source directory from Oliver's home directory once it is confirmed the DNS files are properly stored in the Subversion repository.
RH401-6-en-1-20110713
51
Chapter 4. Using Subversion to Manage Changes
Revision Management with Subversion Preparing to Use Subversion When using Subversion with an existing repository, only a few basic commands are needed to get started. These commands will be introduced in the following pages. Before we examine them, there are a couple of configuration items that need to be taken care of. Subversion requires an environment variable specify which text editor to use to enter log messages. Valid environment variables include EDITOR, VISUAL, or SVN_EDITOR. One of these environment variables should be defined in a Subversion user's .bash_profile configuration file. export EDITOR=vim
In Red Hat Enterprise Linux 6 and recent Fedora versions, the Subversion RPM provides a configuration file for bash that teaches it how to complete Subversion sub-commands. The following added to a user's ~/.bashrc would activate this feature: . /etc/bash_completion.d/subversion
Starting a Working Directory The svn checkout command copies the files of a project from a repository into your current working directory. The Subversion administrator must provide the URL to the repository and the name of the project. Projects can be listed if only the URL to the repository is given: [user@host ~]$ svn list file:///var/local/svn myproject/ oneproject/ twoproject/ ... Output Omitted ...
A project is usually the relative path to a set of related files stored in the repository. A single Subversion repository can store several different projects in its database. Given the output above, the following command would checkout the oneproject project from the repository into a Subversion working directory called oneproject below your current directory: [user@host ~]$ svn checkout file:///var/local/svn/oneproject A oneproject/index.html A oneproject/images A oneproject/images/banner.png A oneproject/images/logo.png Checked out revision 7.
The lines that start with an A indicate these files have been added from the repository into your Subversion working directory.
Committing Changed Files After one has finished editing files in the Subversion working directory, the new revision needs to be put into the repository. The svn commit command accomplishes this task. Without
52
RH401-6-en-1-20110713
Updating a Working Directory
arguments, svn commit will recursively check the current directory and all subdirectories for changed files and commit them to the repository. Log messages are critically important! Before the commit completes, a text editor launches and prompts for a log message which will be associated with this revision. Log messages should be brief descriptions explaining why the changes were made for future reference. When the log message is brief, the -m option can specify the log message on the command line: [user@host myproject]$ svn commit -m 'Restrict cracker.org host access.' Sending etc/hosts.deny Transmitting file data . Committed revision 15.
Particular files can be committed individually. The following command is an example of committing a file that is finished when other files are not ready to be committed: [user@host myproject]$ svn commit filename
Updating a Working Directory As files are edited in a Subversion working directory and the changes are committed, so are the changes of co-workers. If the current Subversion working directory was checked out some time ago, it may not have the latest revision of the files that need to be edited. The svn update command contacts the repository and updates the Subversion working directory with the latest revisions committed. It's a good idea to run svn update at the start of the day (before you start work) and any time a co-worker may have revised a file you plan to edit. Like checkout, update outputs a line for each file updated starting with a letter to indicate the state of the file: • U: The file in the working directory has been updated from the repository. • G: A file in the working directory was in conflict but Subversion was able to update it and merge the changes automatically. • A: There is a new file in your Subversion working directory from the repository. • D: A file was deleted from the Subversion working directory and will be marked as deleted from the repository. • ?: A file is in your working directory, but it does not correspond to anything in the repository, and it is not scheduled for addition to the repository. • M: A file in the repository has local modifications that haven't been saved. • C: There is a modified file with a copy in the repository that has changed and the changes conflict. The changes need to be resolved manually.
Merging Conflicting Changes When a file being committed has changed in the repository since the last update, svn commit will fail. svn update must be executed to merge the changes into the modified working copy. If the changes conflict (for instance, if the edits are on the same line as the changes in the repository copy), the conflict must be resolved. The svn update command displays a C in the first column when conflicts occur.
RH401-6-en-1-20110713
53
Chapter 4. Using Subversion to Manage Changes
[user@host sample]$ svn commit -m "fixed michael's last name" Sending namelist svn: Commit failed (details follow): svn: File '/sample/namelist' is out of date [user@host sample]$ svn update C namelist Updated to revision 29.
When a conflict occurs, four files can be consulted for a possible fix. In the example above, namelist.mine is the original working copy of the file that has the changes that were being committed before the conflict was flagged. namelist.r28 is the pristine version of the file before any changes were made and namelist.r29 is the new update that came from the repository. The file, namelist, is modified so all conflicts are delimited by markers: [user@host sample]$ ls hello namelist.mine namelist.r29 namelist namelist.r28 sample1 [user@host sample]$ cat namelist ... Output omitted ... > .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
Chapter 4. Using Subversion to Manage Changes
svn log filename will output all the log messages recorded for each revision of filename including when and who committed those revisions. The svn cat can be used with the -r option to display a specific revision of a file to standard output. svn cat -rversion filename displays a specific This output can be piped to less for more controlled viewing or it can be redirected to a file for further review: [user@host wrappers]$ svn cat -r 23 hosts.deny | less
Another useful command is svn diff which compares an old version in the repository with the copy of the file in the Subversion working directory: [user@host wrappers]$ svn diff -r 16 hosts.deny
This command may take many different options to output various diff formats. The diff subcommand is useful if the comments in the change log aren't sufficiently clear.
Rolling Back to Old Revisions Sometimes it is necessary to undo all edits made on a file after a particular revision. This can be accomplished with the svn cat command. First the specific revision number of the file in its previous state needs to be identified. This can be accomplished with the svn log and svn diff commands. Use svn cat to display the file in its original, desired state and redirect the output so it overwrites the copy in the working directory. Commit your changes to the repository and mention in the log that a rollback has occurred. The svn revert command discards uncommitted, recent changes to a working copy of a file. This command restores the files specified to the state they were in when they were last updated from the repository.
Properties and Keyword Substitution Subversion maintains additional properties about the files in its repository. You can create and manipulate your own properties or you can use the built-in Subversion properties that impact its behavior. For example the svn:executable property will cause a file to be made executable when checked out of the repository when it is set to a value of 1: [user@host sample]$ svn propset svn:executable 1 hello
The Subversion subcommands to manipulate properties include propset, propget, proplist, propdel, and propedit. Note: properties have to be committed to the repository for them to be persistent. The svn:keywords property contains a string of keywords separated by spaces the Subversion should expand when a file is checked out of a repository. By default Subversion doesn't perform keyword substitution to avoid damaging binary files. Keywords enclosed in dollar signs are expanded only when the svn:keywords property is set: [user@host sample]$ svn proplist sample2 Properties on 'sample2': svn:keywords [user@host sample]$ svn propget svn:keywords sample2
56
RH401-6-en-1-20110713
Next Steps with Subversion
Author Id [user@host sample]$ grep Id sample2 # $Id: sample2 19 2010-02-02 17:31:52Z stapleton $
The following table lists the keywords that Subversion expands: Keyword
Value
Date
The date/time the file was last changed and committed into the repository
Revision
The revision when the file was last updated
Author
The username of the person who committed the last change
HeadURL
The URL that points to this specific file in the repository
Id
A useful combination of the above keywords
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
Chapter 4. Using Subversion to Manage Changes
Practice Exercise
Managing Changes with Subversion Carefully perform the following steps. Ask your instructor if you have problems or questions. Create working directories and observe how Subversion manages concurrent changes by two users. 1.
Log in as oliver on desktopX. If the dnsfiles working directory doesn't exist, check out a working copy of the dnsfiles project below Oliver's home directory.
2.
Change to the top level directory of your Subversion working directory and modify etc/ named.conf. Find the comments that read “REPLACE FIX HERE WITH YOUR STATION NUMBER” and change all occurrences of the string “FIX” in the zone declarations to the last octet of desktopX's IP address. Note: This changes the files that DNS will try to reference. There are comments in the file noting that the actual files must be renamed for consistency. For now disregard those comments since you will fix the repository files to match the new names in a later lab exercise. Commit Oliver's changes with a log message of “Replaced FIX with station's IP.”
3.
In another window, log in as Stan on desktopY. Create a Subversion working directory in Stan's home directory and have Stan checkout a copy of the dnsfiles project. Examine named.conf. The changes made by Oliver should appear in that file.
4.
As Stan, edit var/named/192.168.0.FIX.zone in the Subversion working directory and replace every occurrence of “FIX” with the last octet of desktopX's IP address. Be sure to update the serial number to YYYYMMDD00 using the digits of the current date. Commit Stan's changes with the same log message that Oliver used previously.
5.
On desktopX update Oliver's Subversion working directory so Stan's revisions are incorporated into Oliver's files.
58
RH401-6-en-1-20110713
Next Steps with Subversion
Practice Exercise
Moving Files in a Subversion Project Carefully perform the following steps. Ask your instructor if you have problems or questions. Previously Stan modified the contents of a file. Modify file names and observe how Subversion manages the changes. 1.
Using Stan's account on desktopY, use Subversion to change the name of the 192.168.0.FIX.zone file so “FIX” is replaced with the last octet of desktopX's IP address. Commit the changes into the Subversion repository with a descriptive log message.
2.
Review the log messages of the 192.168.0.X.zone file. Rename the file domainFIX.example.com.zone so “FIX” is replaced with the last octet of desktopX's IP address. Make sure the changes are committed into the Subversion repository.
3.
Examine Oliver's Subversion working directory on desktopX. Use Subversion to update his working files and see what happens.
RH401-6-en-1-20110713
59
Chapter 4. Using Subversion to Manage Changes
Practice Exercise
Subversion Conflict Resolution Carefully perform the following steps. Ask your instructor if you have problems or questions. Observe how Subversion behaves when two users modify the same file, sometimes with conflicting changes. 1.
As Stan on desktopY, open domainX.example.com.zone in a text editor. Modify the SOA line of the file so all occurrences of “FIX” are changed to the last octet of desktopX's IP address. For example the student whose Satellite Server is station3.example.com would modify the line to look like the following: @ IN SOA desktop3.domain3.example.com.
root.desktop3.domain3.example.com. (
Save, exit, and commit the changes to the Subversion repository. 2.
Without updating first, as Oliver on desktopX open domainX.example.com.zone in a text editor. Fix the NS resource record by replacing each “FIX” with the last octet of desktopX's IP address. Save, exit, and have Oliver commit the changes. This shouldn't require too much effort since Oliver's changes do not conflict with Stan's.
3.
Have Stan on desktopY update his Subversion working directory and get Oliver's changes. As Stan, edit domainX.example.com.zone and change each “FIX” in the MX line to the last octet of desktopX's IP address. Update the serial number with the current date followed by a two digit sequence number. Commit Stan's changes to the Subversion repository.
4.
As Oliver on desktopX, make the same changes that Stan made but also change the MX record priority to 15. Attempt to commit your changes. This will fail since Oliver's Subversion working directory is not updated. Also update the zone file serial number to be greater than the previous value. Commit Oliver's changes into the repository since his changes are more complete than Stan's changes.
5.
60
As either Oliver or Stan, update the remaining resource records in domainX.example.com.zone that contain “FIX” with desktopX's number. Update the serial numbers in the .zone zone files. Commit the changes into the Subversion repository.
RH401-6-en-1-20110713
Next Steps with Subversion
Personal Notes
RH401-6-en-1-20110713
61
Chapter 4. Using Subversion to Manage Changes
Unit Summary Revision Control Concepts In this section you learned: • The benefits of using revision control • How Subversion works at a high level • How to select a Subversion repository . Subversion Administration In this section you learned how to: • Create a new Subversion repository • Secure a Subversion repository • Start a project in Subversion . Revision Management with Subversion In this section you learned how to: • Check out a Subversion working directory • Commit changes made to files in a project • Update a Subversion working directory with changes made by others • Merge and resolve changes that conflict • Adding, deleting, and changing file names in a project • Roll back to a previous edition of a file .
62
RH401-6-en-1-20110713
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
Chapter 5. Red Hat Network Client Configuration
Interactive Client Registration Update RHN Client Software Before registering a client with Red Hat Network, it is important to bring the registration and package updating software up to date. Sometimes newer packages are needed because of features provided by the updated tools or changes in their configuration. In practice the registration process will perform this function for you, but you may wish to do this yourself if you are scripting the installation. Publish the latest versions of the software packages listed below on your RHN Satellite Server's web site. The best place to provide these files is under the http://satellite.fqdn/pub directory. Have the client systems download and freshen these packages before they register with Red Hat Network. For example, a command similar to the following should be run for each package: [root@host ~]# rpm -Fvh http://satellite.fqdn/pub/yum-version.i386.rpm
• Install the latest version of RHN-related packages • Red Hat Enterprise Linux 5 and later packages • rhn-setup • rhn-setup-gnome • yum • Pre-Red Hat Enterprise Linux 5 packages • rhn_register • rhn_register-gnome • up2date • up2date-gnome
Red Hat Network Server Selection When a system is installed with Red Hat Enterprise Linux, it is configured to point to hosted Red Hat Network by default. The assumption is that the new system will talk directly with Red Hat's servers over the Internet (https://xmlrpc.rhn.redhat.com/XMLRPC). /etc/sysconfig/rhn/up2date is the primary configuration file for Red Hat Network client tools. Many of the registration programs modify settings in that file or the changes can be scripted or made manually. For example, the serverURL directive defines which RHN server should be queried for updates: serverURL=https://satellite.fqdn/XMLRPC
Additionally, HTTP/HTTPS proxy settings can also be defined by assigning the following values in /etc/sysconfig/rhn/up2date:
66
RH401-6-en-1-20110713
Secure Communication with SSL
enableProxy=1 httpProxy=hostname:port
Note Always use fully qualified domain names when specifying Red Hat Network Satellite and/or Proxy servers.
Secure Communication with SSL A best practice is to have all Red Hat Network communication secured using SSL encryption. SSL server certificates must be considered trustworthy before a secure communication tunnel is created. Certificate authority (CA) certificates are used to confirm the authenticity of a host's SSL server certificate. The CA certificate used to verify Red Hat's server certificates can be found in a file called /usr/share/rhn/RHNS-CA-CERT. Red Hat installation media deploys an RPM called rhn-client-tools that installs this CA certificate on all Red Hat Enterprise Linux hosts by default. The Red Hat Network Satellite Server and Proxy Server installers generate a CA certificate, an RPM package which includes the CA certificate, and an SSL server certificate signed by the CA certificate. Installing the RPM package with the CA certificate causes clients to trust the server's SSL certificate. This RPM is normally distributed through the Satellite Server's web site in the /pub directory and the RPM is typically called: rhn-org-trusted-sslcert-1.0-1.noarch.rpm. This RPM must be installed on every client who connects to a Red Hat Network Satellite or Proxy server using SSL. This is defined by sslCACert in /etc/ sysconfig/rhn/up2date.
Red Hat Network Authentication User accounts are unique on Red Hat Network Hosted and on a Red Hat Network Satellite Server. On a RHN Satellite Server each user account, and systems registered using that account, belong to the organization the account was originally created in. Unless there is a universal default activation key, the newly registered system does not belong to any system groups. Users must authenticate using a RHN user account. User accounts used to register systems do not have administrative privileges to administer those systems by default. To enable RHN users to administer clients they register, the client systems will have to join a system group the users have permissions to administer. An Organization Administrator can modify user accounts so that systems they register automatically join default system groups for that account. Each registration consumes one Red Hat Network entitlement. Minimally this includes a base slot and a base software channel entitlement. Optionally add-on and child channel entitlements could be included. Another option is to create a universal default activation key that associates newly registered systems to a generic system group that every RHN user can access. Note that activation keys override default system group assignments associated with a user account.
RH401-6-en-1-20110713
67
Chapter 5. Red Hat Network Client Configuration
References Red Hat Network Satellite Reference Guide • Chapter 2: The rhn_register Client rhn_register(8) man page
68
RH401-6-en-1-20110713
Secure Communication with SSL
Practice Performance Checklist
Graphical Red Hat Network Registration You will register a system with a Red Hat Network Satellite using rhn_register in a graphical environment. Since SSL encryption will be used, the organization CA certificate will have to be located and used when registering the client system. Your client workstation, desktopY.example.com, should already be installed to provide a graphical environment. The classroom installation configures yum to point to the instructor's server for additional RPMS. Remove the /etc/yum.repos.d/ dvd.repo configuration file and reset yum by executing the following command as root: [root@desktopY ~]# yum clean all [root@desktopY ~]# rm /etc/yum.repos.d/dvd.repo
Browse http://desktopX.example.com/pub and locate the CA certificate for the local organization provided by the Satellite Server. Download the CA certificate to the / tmp directory on desktopY. Log in as root on desktopX and monitor your Satellite server's Apache log files. Use tail -f to monitor them continuously. Open a terminal window on desktopY and execute rhn_register so it displays a graphical dialog box. Configure the client to use the Satellite Server, desktopX.example.com, for software updates. Use the SSL certificate you previously downloaded and authenticate as the Red Hat Network user normal. Once the client is configured, use yum repolist to verify it is talking with the Satellite Server. Use a web browser to log into the Satellite server web user interface as normal and see if the newly registered system shows up in the system list. Do the same for the Red Hat Network user grouper. Finally log in as the Organization Administrator, example, and see if the client shows up in his system list.
RH401-6-en-1-20110713
69
Chapter 5. Red Hat Network Client Configuration
Practice Performance Checklist
Text-based Red Hat Network Registration Register a system with a Red Hat Network Satellite using rhn_register in a text-based environment. You should already have the CA certificate copied to the filesystem on the client machine. Log into a text-based virtual console (Ctrl+Alt+F2) as root on desktopY and execute rhn_register to re-register your client with your Satellite server. When rhn_register asks for RHN authentication information, provide the login of normal with the password redhat. Log into the Satellite server web interface as example. There should be two system profiles labeled desktopY.example.com.
70
RH401-6-en-1-20110713
Registration Automation: Activation Keys
Registration Automation: Activation Keys One major benefit of activation keys is they remove the requirement to authenticate as a Red Hat Network user when registering a client system with RHN. This greatly facilitates automation of system registration. Activation keys also automate other Red Hat Network functions such as subscribing to child software channels, joining system groups, installing specific packages or including add-on entitlements such as Provisioning, monitoring, virtualization, virtualization platform, etc. Multiple activation keys can be used when registering a system with RHN, so there are a couple of approaches that can be taken when using them. One approach uses a single activation key to perform multiple actions on the RHN Satellite server. The other approach involves several activation keys, with each key performing a single, simple action on the Satellite server. When systems are registered using this approach, multiple keys are used together in various combinations depending on what needs to be accomplished for a given client system. This approach has more flexibility in terms of activation key maintenance. One activation key can be designated as the “universal default” activation key for an organization. Each organization has its own universal default and only one activation key can be designated as the universal default. The actions and associations assigned to the universal default are taken for hosts that register with an organization without an activation key. It is a best practice to assign a universal default activation key that assigns a newly registered system to a system group as a minimum. Activation keys are an essential component to Red Hat Network client registration automation. Use the procedure below to generate an activation key. Each activation key has five attributes: 1.
Description of what the key is for
2.
Usage limit - number of times the key may be used for activation
3.
Base software channel the client should subscribe to when activated
4. Add-on entitlements such as Provisioning, Monitoring, Virtualization, or Virtualization Platform 5.
A flag indicating whether a key is the universal default
After an activation key is created, additional attributes can be associated with the key such as: • Child software channels • Packages to install at registration time • One or more system groups to join Clients may only subscribe to relevant software channels. For example a Red Hat Enterprise Linux 5 Server host cannot subscribe to the Red Hat Enterprise Linux AS 4 channel. Use the activation key to register a system with the Satellite server at client installation time.
Activation Key Creation • Generate an activation key on the RHN Satellite server:
RH401-6-en-1-20110713
71
Chapter 5. Red Hat Network Client Configuration
• Login as an Organization or Activation Key Administrator • Click on the Overview tab • Select the Manage Activation Keys task • Follow the create new key link • Provide a key description, a key name, usage limit, base software channel and whether it is the universal default for the organization • Click Create Activation Key
RHN Registration Using an Activation Key An activation key can be used without the necessity of RHN authentication. Use the following command to invoke rhnreg_ks with the essential options needed to specify the target RHN server, the needed CA certificate for SSL encryption, and the activation key: rhnreg_ks --serverUrl=https://satellite.fqdn/XMLRPC \ --sslCACert=/path/to-ca-cert \ --activationkey=activation-key-name
To interactively register a system to a satellite server, run rhn_register [--nox] and answer all questions posed. You can also modify /etc/sysconfig/rhn/up2date and update serverURL and sslCACert values before running rhn_register to provide some default answers. Since Red Hat Network Satellite Server version 5.2, the activation key has a numeric prefix (for example, 2-webserver). This prefix represents the organization ID that prefixes every activation key created and associated within that organization. To specify multiple activation keys with the rhnreg_kscommand, a single --activationkey option is specified followed by a comma-separated list of activation key names. Specifying multiple --activationkey options does not work like one might expect: the last option specified is the only activation key that is applied. To re-register a system already registered with Red Hat Network, perform the following steps: 1.
Delete the original system profile from Red Hat Network to reclaim entitlements
2.
Use the --force option with rhn_register or rhnreg_ks
72
RH401-6-en-1-20110713
RHN Registration Using an Activation Key
References Red Hat Network Satellite Reference Guide • Section 7.4.6: Activation Keys • Section 4.5: Registering with Activation Keys Red Hat Network Satellite Client Configuration Guide • Section 2.2.1: Registering with Activation Keys rhnreg_ks(8) man page
RH401-6-en-1-20110713
73
Chapter 5. Red Hat Network Client Configuration
Practice Exercise
Automating Registration with Activation Keys Carefully perform the following steps. Ask your instructor if you have problems or questions. The previous exercises demonstrated how to register a machine with a Red Hat Network Satellite Server using interactive utilities. Automate the registration process by creating an activation key that registers with the Example RHN organization and use it to re-register your client. 1.
Log into your Satellite server as example and create an activation key named exampleservers. It should have a description of “Example Servers”, not have a usage limit, and subscribe the client to the default RHN Satellite base channel for the system being installed. This activation key should not consume any add-on entitlements and do not use it as the universal default. All systems registered with this activation key should automatically join the example systems system group.
2.
Log in as root on the client, desktopY.example.com, and use rhnreg_ks to register your system using the activation key you just created. If the registration doesn't work immediately, diagnose what the problem is and fix it. The Satellite Server host name and information about the CA certificate already have useful default values. Normally they would have to be specified, but the previous registrations modified /etc/sysconfig/rhn/up2date so it points to valid values so the defaults can be taken.
3.
74
Check the system profile of your client system in the Satellite Server. Is it a member of the example servers system group? If not, make the necessary adjustments to your activation key and re-register the client again. When you are finished with this exercise, delete all of the system profiles in the Satellite Server.
RH401-6-en-1-20110713
Registration Automation: bootstrap.sh
Registration Automation: bootstrap.sh Many steps must be taken to register client machines with a RHN Satellite Server. The bootstrap.sh script can be used to fully automate this process. By default, this script contains a few useful commands, but you can expand it to do whatever you wish. It may be used in a kickstart %post section or it can be manually executed on a freshly installed Red Hat Enterprise Linux host. If rhnreg_ks is invoked with an activation key from the bootstrap.sh script, a system can be registered with Red Hat Network before its first boot. The following steps outline the process of creating the bootstrap.sh script using the RHN Satellite web interface: • Login as the Satellite Administrator (not an Organization Admin) • On the Overview tab, select Configure RHN Satellite • Select the Bootstrap Script tab • Make any adjustments, then click Update bootstrap.sh is disabled by default (contains exit 1 shell command). It is a good starting point/template, and can be used with activation keys. To create bootstrap.sh: • Use web interface as Satellite Admin (not Organization Admin) • Use the rhn-bootstrap command on the Satellite Server • Result is http://satellite.fqdn/pub/bootstrap/bootstrap.sh
References Red Hat Network Satellite Client Configuration Guide • Chapter 5: Using RHN Bootstrap • Appendix A: Sample Bootstrap Script rhn-bootstrap(1) man page
RH401-6-en-1-20110713
75
Chapter 5. Red Hat Network Client Configuration
Practice Exercise
Registering Clients with a Bootstrap Script Carefully perform the following steps. Ask your instructor if you have problems or questions. Red Hat Network Satellite software can create a template shell script, called a bootstrap script, that can register a client system with the Satellite server. Customize and use a bootstrap script to register a freshly installed system with your Satellite server. 1.
Reinstall your client workstation, desktopY, with a minimal footprint installation. Initiate a PXE boot and choose the “Install a minimal RHEL 6 installation” option without any arguments to begin the installation. While desktopY is installing, continue to the next step.
2.
A Satellite Server provides bootstrap scripts to all of its clients, not just to a specific organization, so they must be created and managed by the Satellite Administrator. While the client workstation installs, log in as the Satellite Administrator, satadmin, and in the web interface create a bootstrap script template as a starting point. The script should enable SSL and client GPG checking. It should not enable remote configuration and remote commands. These options will be introduced later in the course. Optional - Use Subversion to manage the changes you make to the bootstrap script you develop. Create a new Subversion project and check in the original version before you make any changes.
3.
Edit your bootstrap script on your Satellite Server. Disable the exit 1 line and modify the ACTIVATION_KEYS shell variable to point to the activation key you created earlier in this lab.
4.
Once the client machine has finished installing, log in as root, download the bootstrap script, and execute it manually. Normally this step would be performed in the %post section of a kickstart installation for full automation. Sign into the Satellite Server web interface as normal and confirm the system is registered and belongs to the example-servers system group.
76
RH401-6-en-1-20110713
Resolving Registration Problems
Resolving Registration Problems To begin resolving RHN registration issues, start with network connectivity issues: • Can the RHN server be pinged? • Does DNS work properly? • Having an HTTP/HTTPS proxy or firewall issue? • Do all references to the Satellite server use its FQDN? From the client, use rhn_check and rhn-profile-sync -vv to view errors. The following are the most common “Error Class Codes”: • 9 - client not registered • 70 - no entitlements available Once basic connectivity issues are resolved, there are a couple of other areas that should be checked concerning Red Hat Network client/server communication. First, the fully qualified domain name should always be used when referring to the Red Hat Network server, whether it is hosted RHN, a RHN Satellite Server, or a RHN Proxy Server. The fully qualified domain name should resolve to the appropriate IP address for the server. If DNS isn't functioning, a temporary entry could be made in /etc/hosts for testing purposes. Ultimately any long-term solution would fix DNS name resolution. When using SSL encryption for secure communication, the clocks of the Red Hat Network hosts (both client and server) need to be accurate and synchronized. A good solution for this is to use NTP to keep all the system clocks set to an accurate time to enable SSL to work. Also make sure the fully qualified host name of the Satellite server is being used since the subject of the host certificate is the FQDN of the server. Red Hat Network creates a new host profile when a system re-registers with RHN (for example using rhn_register with the --force option). When multiple profiles exist for a specific host, its old, unused profiles should be removed to free up system and software entitlements. First, determine the current system ID of the RHN client: [root@host ~]# grep ID /etc/sysconfig/rhn/systemid 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
Chapter 5. Red Hat Network Client Configuration
Personal Notes
78
RH401-6-en-1-20110713
Resolving Registration Problems
Unit Summary Client Registration Concepts In this section you learned: • RHN client registration concepts . Interactive Client Registration In this section you learned how to: • Update RHN Client Software • Select the Red Hat Network Servers • Secure Communication with SSL . Registration Automation: Activation Keys In this section you learned how to: • Create an activation key • Use an activation key to automate RHN registration . Registration Automation: bootstrap.sh In this section you learned how to: • Automate registration using bootstrap.sh . Resolving Registration Problems In this section you learned how to: • Resolve RHN registration issues .
RH401-6-en-1-20110713
79
80
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
Chapter 6. Red Hat Network Software Management
Preparing RPMs for Red Hat Network RPM packages are normally digitally signed so that users can verify that a package actually came from the preparer it claims to belong to. This helps to block forged packages from being installed if a yum repository is compromised in some way. The next few steps detail how to create your own signing key. To create a custom channel, you must take some preliminary steps: 1.
Generate a GPG key for the user account who manages RPMS and will load them into the Satellite Server.
Note You must have a graphical session open to run gpg --gen-key. It uses a graphical box to accept your input for the passphrase.
[user@host ~]$ gpg --gen-key gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? Enter RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Enter Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = 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
Chapter 6. Red Hat Network Software Management
References Red Hat Network Satellite Channel Management Guide • Chapter 4: Custom Channel and Package Management
86
RH401-6-en-1-20110713
Preparing RPMs for Red Hat Network
Practice Exercise
Custom Software Channel Administration Carefully perform the following steps. Ask your instructor if you have problems or questions. Create Linux and RHN Satellite accounts for the responsible person who is in charge of managing custom channel content. Create a GPG key for signing trusted third-party packages. Once the pieces are in place, create a custom software channel for Example, Inc. third-party software packages. 1.
Create Linux and RHN Satellite accounts on desktopX.example.com for Charles Channelman, the person responsible for managing software channels on the Satellite Server. The login/user name for his accounts should be channelman with passwords of redhat. His Red Hat Network account on the Satellite Server should permit him to manage software channels and the systems in the example servers system group.
2.
Log into a shell account on desktopX as channelman and create a GPG key. The key should be a 2048-bit RSA key used for signing packages only. It shouldn't expire and should be protected with a passphrase of redhat. The owner of the key should be “Charles Channelman ”. 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
Chapter 6. Red Hat Network Software Management
Loading RPMS into RHN Satellite The satellite-sync and rhnpush commands import RPMS into a Red Hat Network Satellite Server. satellite-sync loads multiple RPMS, SRPMS, channel metadata, and kickstart trees into the server. This command is typically used with Red Hat content. The rhnpush command is used to import individual RPMS and SRPMS. This command is used with custom packages/thirdparty software. Both of these tools are used from the command-line so shell access is required. The Red Hat Network web interface does not provide a way to import software into a Satellite Server or RHN Proxy.
Using satellite-sync Software channel content can be transferred and loaded from Red Hat's servers via the Internet. This is the default behavior of the satellite-sync utility. Without special options, it interacts with the local Satellite Server and Red Hat's hosted RHN servers to try to keep the local Satellite server in sync. Channel content ISOs can be downloaded from Red Hat Network. Each ISO in a set is mounted and its contents are copied into a temporary directory. satellite-sync is used with the -m option to load the extracted content into the Satellite Server. The content is deleted from the temporary directory as it is imported into the Satellite Server. Using the above two methods to import channel content into a RHN Satellite Server was discussed in more detail earlier in this course in the Installation unit. A third method to get channel content is from a channel dump created from another Satellite Server using the rhnsatellite-exporter command. Creating channel dumps will be covered later in this course, but importing channel dump content into a RHN Satellite Server is the same as importing content extracted from ISOs, the satellite-sync command is used with the -m option to point to the channel dump content. This is what you did earlier in the course when you installed your Satellite Server and imported channel content. The satellite-sync command is used from the command line on the Satellite Server. It doesn't require Red Hat Network authentication, but it does require root access on the Satellite Server to work.
Warning satellite-sync removes packages from the channel content it is importing to help conserve disk space. If the channel content will be reused for other Satellite servers or will be kept as a backup, then the media it is stored on should be mounted read-only.
Other useful options to satellite-sync include -l which lists the available channels, and -c channel-to-sync which specifies the channel name to sync.
Using rhnpush The rhnpush command is used to import individual binary and source RPMS into a Satellite Server. It is a command-line utility that doesn't require root privileges and it doesn't have to
88
RH401-6-en-1-20110713
Using rhnpush
be executed from the RHN Satellite Server. The rhnpush RPM provides this utility and can be installed on any system that is subscribed to the Red Hat Network Tools software channel. When a channel is specified, the RPM is imported into that channel and its corresponding organization. An RPM can be imported into multiple channels when multiple -c options are specified. When the channel is omitted, the RPM is loaded into the No Channels section of the organization specified with the -o option. The default configuration file for rhnpush is located at /etc/sysconfig/rhn/rhnpushrc. It can be copied to ~/.rhnpushrc and modified with preferred settings for a particular user/ RPM administrator. Command-line options override any of the values specified in these files. The following are a couple useful directives: server username
= https://satellite.fqdn/APP = RHN-login
The rhnpush command imports RPM content into RHN Satellite Servers. There is another tool that imports content into RHN Proxy Servers, but that utility will be introduced in a later unit. Option
Function
--server=https://hostname/APP
push packages into the RHN Satellite server specified
-l
list the specified channels
-c channel-label
channel to list or import packages into
-o org-ID
associate a package with an organization (when -c is not specified)
--source
indicates the package being pushed is a source RPM
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
Chapter 6. Red Hat Network Software Management
Practice Exercise
Loading Red Hat Content into RHN Satellite Carefully perform the following steps. Ask your instructor if you have problems or questions. All Red Hat base software channels have a child channel called “Red Hat Network Tools.” This channel provides useful packages for machines that are clients of a RHN Satellite Server. •
90
Log in as root on desktopX. In root's home directory you will find a subdirectory called sat-rhel6-content. Examine its contents and import the channel that provides the “Red Hat Network Tools” which pertain to the base channel content you already loaded in your Satellite Server.
RH401-6-en-1-20110713
Using rhnpush
Practice Performance Checklist
Loading Third-party Content into RHN Satellite As channelman, take a third-party RPM provided by the instructor, sign it, and import it into the RHN Satellite Server and associate it with the example-custom software channel. Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the example-1.0-1.noarch.rpm RPM from /misc/instructor/RPMS to Charles' home directory, and sign it with his GPG key. Import the RPM into the Satellite Server so it is associated with the example-custom software channel.
RH401-6-en-1-20110713
91
Chapter 6. Red Hat Network Software Management
Using a Custom Channel Once created and populated, the channel can then be associated with particular systems. Subscribe client systems to the channel. The yum list available command can be used to confirm the client is subscribed to the custom channel. For example, the following command will confirm whether a client is subscribed to a custom channel with a channel label of exampleextras: [root@host ~]# yum list available | grep example-extras
Once the channel subscription is verified, use yum to install packages on particular systems or schedule the installation of the software using the Satellite Server's web interface. Log into RHN Satellite Server web interface as • System Group User who can manage the target system, or • Organization Administrator Navigate to the Alter Channel Subscriptions link • Select the Systems tab • Choose the Systems link in the navigation bar to the left • Select the target host's link by its profile name • Click the Alter Channel Subscriptions link • Check desired channels, click Change Subscriptions Use yum to list available software from this channel
References Red Hat Network Satellite Channel Management Guide • Section 2.2: Subscribing to Channels
92
RH401-6-en-1-20110713
Using rhnpush
Practice Performance Checklist
Subscribing to a Custom Channel Associate your client system, desktopY.example.com, with your custom software channel and install the example RPM on the client host. Subscribe your client system to the example-custom custom software channel. Import the GPG key used to sign the packages provided by the custom channel into the RPM database on the client system. Install the example RPM on the client machine using the yum command.
RH401-6-en-1-20110713
93
Chapter 6. Red Hat Network Software Management
Software Management Using Cloned Channels Cloning Channels Cloning software channels is another way to create custom software channels. Typically, cloning is used to create a custom software channel populated with packages from Red Hat rather than third party software or custom RPMS. Cloned channels can be customized to fit the administrator's needs. For example, unneeded RPMS can be deleted from the list of available packages. Note this only affects the clone, not the original channel from Red Hat. If a mistake is made, RPMS can easily be added back to the clone. Also specific versions of packages can be merged into a cloned channel. In other words, both the width and the depth of a cloned channel can be customized with respect to the packages that are offered. Cloned channels do not provide kickstart installation trees. Installations can use standard Red Hat channels for builds then subscribe to cloned channels for more controlled RPM releases. Cloning provides complete control over release of packages. Updates from Red Hat can be merged back by Channel Admins. Although this requires more work to set up initially, you have complete control over package releases.
Software Management Life Cycle The primary goal of the software management life cycle is to control which packages and updates are available for installation on the client systems. Cloned software channels allow system administrators to publish a subset of packages originally from a Red Hat channel. Also errata can be cloned and published after they have been thoroughly tested. One possible use of cloned channels involves three types of systems: development, QA, and production. Development machines use packages directly from Red Hat. Programmers and prototype systems have the latest and greatest releases of packages available to them. Once a solution has been built, specific versions of RPMS can be merged with the QA channels for testing purposes and software validation. Once QA verifies the soundness of the updates, they are merged into the production channels. A variation on the above scheme uses a cloned channel for development purposes instead of using pristine Red Hat channels. This provides an additional level of control over software deployed to development machines. Software channel cloning controls which packages are made available to the client systems, but how the packages are deployed is another consideration. RHN client machines can be configured to automatically install errata so there is no manual effort required to propagate updates. This could be accomplished by periodically invoking yum -y update from a cron job. Other Red Hat Network users prefer to install available errata manually during a scheduled downtime.
Creating a Cloned Channel To clone a software channel, log into RHN Satellite Server web interface as a Channel Administrator or an Organization Administrator. Select the Channels tab, Manage Software Channels from the menu at the left, then click the clone channel link. Use the pull-down menu to choose the original channel to clone from then pick which errata to include. A channel can be cloned from its original state, its current state, or specific errata can be selected to be included
94
RH401-6-en-1-20110713
Updating a Custom Channel RPM
in the clone. Once the basis for the clone has been determined, the remaining screens are similar to those that appear when a custom software channel is created - a channel name and summary are chosen and user and organization access are assigned. Cloning a base software channel does not clone its child channels automatically. Each of the software channels in related family of channels must be cloned individually.
Updating a Custom Channel RPM Packages that belong to custom channels will eventually need to be updated. Build the updated RPM in the usual way, being sure to increment the version or release. Then you use rhnpush to import the new package into the Satellite Server. The Satellite Server will recognize it as a more recent version of the package and will automatically make it available to systems subscribed to the software channel which contains the update. If the custom channel has been cloned, the update will not propagate automatically - it must be merged with the cloned channels. Once the new package is ready for distribution, an errata notification can be published to send an e-mail making system administrators aware of the update. This step isn't required, but it is a best practice to group related packages that fix a related problem together with an errata.
References Red Hat Network Satellite Channel Management Guide • Section 4.7: Cloning Software Channels
RH401-6-en-1-20110713
95
Chapter 6. Red Hat Network Software Management
Practice Performance Checklist
Managing Updates with Cloned Channels Create clones of standard Red Hat channels and custom channels to control how software updates are rolled out to client systems. Create clones of standard Red Hat software channels (both base and child channels) and the custom software channel in your Satellite Server. These channels will be “Production” versions of their original counterparts so assign them labels identical to the original channels with a “prod-” prefix. Use the default values provided for the access controls of the cloned channels. Change the subscriptions of your client machine, desktopY, so it subscribes to the new cloned channels. Include “production” versions of the base channel and the Example custom child channel. Remove, then reinstall, the example RPM and confirm it comes from one of the cloned channels just created.
96
RH401-6-en-1-20110713
Managing Software Updates
Managing Software Updates All errata management is handled by Organization Administrators and/or Channel Administrators since it is a software management function. Selecting the Errata tab will bring up a menu to the left that includes Manage Errata and Clone Errata links. This is where errata management occurs. When creating an erratum, an advisory field needs to be specified. Note that customer generated advisories cannot begin with the letters RH. These are reserved for Red Hat generated advisories. Cloned errata derive their advisory names from the original and replace the RH* prefix with CLA, which stands for CLoned Advisory. Also the severity of the erratum need to be selected, whether for a software enhancement, a bug fix, or a security related issue. Once an erratum is created and packages are assigned to it, the final step is to publish the erratum. Optionally an e-mail notification can be sent to the administrators of relevant systems. It usually takes a few minutes for published errata to become available to client systems. This delay allows for all pieces of each erratum to be in place before client systems try to access them. Errata can be cloned, but it is restricted to channels cloned from the channel of the original errata. Best practice: Always clone errata instead of the updated RPMS individually. This approach to cloning updates preserves errata data.
References Red Hat Network Satellite Channel Management Guide • Chapter 5: Custom Errata Management
RH401-6-en-1-20110713
97
Chapter 6. Red Hat Network Software Management
Practice Exercise
Update Notifications with RHN Errata Carefully perform the following steps. Ask your instructor if you have problems or questions. Sign and import a newer (fixed) RPM into the Satellite Server. Create an errata to notify client system administrators that a fix has been published. Observe its impact on the client systems. 1.
Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the improved RPM, example-1.0-2.noarch.rpm, from /misc/instructor/RPMS to Charles' home directory and sign it with his GPG key. Import the new RPM into the Satellite Server so it is associated with the example-custom software channel.
2.
Create and publish an errata notification that announces the availability of the example-1.0-2.noarch.rpm package. The errata synopsis should read, “example - file ownerships fixed”. Advisory EXBA2010:0001 release 1 is a bug fix advisory.
3.
Browse the Satellite Server's web UI and verify that the Errata is published. Notice that the client system is not impacted because we changed its software channel subscriptions to the Production channels.
4.
Clone the errata and make it available to the prod-example-custom channel. Log into the client system, desktopY, as root and confirm the new RPM is available for installation. Note: The update may take up to 10 minutes to become available for installation because the default yum settings cause metadata to expire after 10 minutes. Use yum clean all to clear the caches and verify you can view the update.
98
RH401-6-en-1-20110713
Managing Software Updates
Personal Notes
RH401-6-en-1-20110713
99
Chapter 6. Red Hat Network Software Management
Unit Summary Software Channels In this section you learned how to: • Describe the base/child relationship between software channels . Custom Software Channels In this section you learned how to: • Create and manage custom software channels . Loading RPMS into RHN Satellite In this section you learned how to: • Use satellite-sync to import Red Hat channel content • Use rhnpush to import custom channel content . Using a Custom Channel In this section you learned how to: • Subscribe a client to a custom software channel . Software Management Using Cloned Channels In this section you learned how to: • Create and manage cloned software channels . Managing Software Updates In this section you learned how to: • Create, clone, and manage errata .
100
RH401-6-en-1-20110713
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
Chapter 7. Building RPMs
Spec File Directives and Sections Important Preamble Directives • Name - The name of the package, usually chosen by the developers. For detailed guidance, look at the Fedora Naming Guidelines, at http://fedoraproject.org/wiki/Packaging:NamingGuidelines • Version - The version of the package (usually numeric), usually chosen by the developers. • Release - The release of the package, chosen by the packager. This should increase each time you release a new package for distribution if you still use the same Version of the software. • Group - The group to which the package belongs. See /usr/share/doc/rpm-*/GROUPS for the default set of groups, or use one of your own. This field is semi-obsolete and is not related to yum package groups. • URL - The web page of the open source software • License - The “Short License identifier” of the license used for the software. Detailed guidance on how to set this in a standard way can be found at http://fedoraproject.org/wiki/ Packaging/LicensingGuidelines • Summary - A short one-line description of the software. (Keep to about 50 characters or less.) • Source - The file to be used as the source code. If there are more than one file used as source, add a number. E.g., Source0, Source1, Source2, etc. • BuildArch - The architecture to use when building the package. Defaults to the system architecture. A common argument is noarch, which means that the package is architecture independent (often these packages consist of scripts or data files). • Requires - A list of explicit requirements this package depends on. This could be a list of files or other packages. rpmbuild can generally autodetect most library dependencies, but there are some cases where you may need to list an explicit dependency. See http://fedoraproject.org/ wiki/Packaging/Guidelines#Requires for additional guidance on Requires. • BuildRequires - A list of requirements that are needed to build this package. This is a list with similar syntax to that of Requires, for example BuildRequires: /usr/bin/gcc, gimp-libs >= 2.6.11. See the link in Requires above for information on how to tell if you need missing BuildRequires.
Spec File Sections • %description section - A long description of the software. No line should be more than 80 characters long, but you may have multiple lines. • %prep section - Uncompress and unarchive files in the BUILD directory. Prepare for the build phase. • %build section - Build the software (optional). Compile the software if needed.
104
RH401-6-en-1-20110713
Spec File Sections
• %install section - Install the files in the correct location. The make command usually uses the DESTDIR=$RPM_BUILD_ROOT. If you copy or install files, the destination is usually prepended with $RPM_BUILD_ROOT so the software will be placed in the chroot'ed environment in preparation for packaging. • %clean section - Post build cleanup. This section usually includes: rm -rf $RPM_BUILD_ROOT to clean the chroot environment. • %files section - All files should be included here. You may mark files as %config or %doc which are presented with rpm -qc and rpm -qd, respectively. • %changelog section - A log of changes made to the software. Include the bug tracking numbers if used. This information can be displayed with rpm -q --changelog.
References Fedora RPM Guide http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ Fedora Packaging Guidelines http://fedoraproject.org/wiki/Packaging:Guidelines
RH401-6-en-1-20110713
105
Chapter 7. Building RPMs
Practice Quiz
RPM Spec File 1.
The package is usually derived from the open source project while the package is the packager's version.
2.
The name of the tarball containing the files used to build the package is specified with the directive.
3.
The directive specifies the target architecture the package is being built for. will be its value when the package can be installed on any architecture.
4.
The directive specifies the one-line description of a package while the section provides a more thorough explanation of what that package is for.
5.
The in the
6.
The section defines which files and directories to package into the RPM.
7.
The , , and sections contain shell code used to assemble a package and clean up after it has been built.
106
section contains the code used to place files chroot directory structure.
RH401-6-en-1-20110713
Creating a Spec File
Creating a Spec File On Red Hat Enterprise Linux 6, vim has a macro that helps to create a specification file. Simply pass a file name that ends in .spec: [user@host ~]$ vim sample.spec
The Red Hat Enterprise Linux 6 version of vim will use the spec template to provide some common entries for RPM building.
Note When an RPM package is built, a source RPM (SRPM) package is also created, with an architecture of src. Another way to get a spec file is to install a source package by running rpm -ivh package-1.2.3-4.src.rpm as a non-root user. The spec file for the package will be in ~/rpmbuild/SPECS.
Example Spec File An annotated example of a spec file follows. %define %define %define %define %define %define
debug_package %{nil} product_family Red Hat Enterprise Linux release_name Santiago base_release_version 6 full_release_version 6.0 beta Beta
Name:
redhat-release
Version:
%{base_release_version}
Release:
6.0.0.24%{?dist}
Summary: Group: License:
%{product_family} release file System Environment/Base GPLv2
Obsoletes:
rawhide-release redhat-release-as redhat-release-es redhat-release-ws
Source0:
redhat-release-6-4.tar.gz
%description %{product_family} release files %prep %setup -q %build echo OK %install rm -rf $RPM_BUILD_ROOT
RH401-6-en-1-20110713
107
Chapter 7. Building RPMs
# create /etc mkdir -p $RPM_BUILD_ROOT/etc # create /etc/system-release and /etc/redhat/release echo "%{product_family} release %{full_release_version}%{?beta: %{beta}} (%{release_name})" > $RPM_BUILD_ROOT/etc/redhat-release ln -s redhat-release $RPM_BUILD_ROOT/etc/system-release # write cpe to /etc/system/release-cpe echo "cpe:/o:redhat:enterprise_linux:%{version}:%{?beta:%{beta}}%{!?beta:GA}" > $RPM_BUILD_ROOT/etc/system-release-cpe # create /etc/issue and /etc/issue.net cp $RPM_BUILD_ROOT/etc/redhat-release $RPM_BUILD_ROOT/etc/issue echo "Kernel \r on an \m" >> $RPM_BUILD_ROOT/etc/issue cp $RPM_BUILD_ROOT/etc/issue $RPM_BUILD_ROOT/etc/issue.net echo >> $RPM_BUILD_ROOT/etc/issue # copy yum repos to /etc/yum.repos.d mkdir -p $RPM_BUILD_ROOT/etc/yum.repos.d for file in *.repo; do install -m 644 $file $RPM_BUILD_ROOT/etc/yum.repos.d done # copy GPG keys mkdir -p -m 755 $RPM_BUILD_ROOT/etc/pki/rpm-gpg for file in RPM-GPG-KEY* ; do install -m 644 $file $RPM_BUILD_ROOT/etc/pki/rpm-gpg done # set up the dist tag macros install -d -m 755 $RPM_BUILD_ROOT/etc/rpm cat >> $RPM_BUILD_ROOT/etc/rpm/macros.dist /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
Chapter 9. Provisioning with PXE
[user@host ~]$ rpm -ql syslinux | grep pxelinux
pxelinux.0 is a network-aware boot loader. Once executed by the client system's BIOS, pxelinux.0 searches the same directory from which it was downloaded for a configuration file in the pxelinux.cfg/ subdirectory. The loop ends on the first successful get operation. This procedure is documented in /usr/share/doc/syslinux-*/pxelinux.doc. Additional files from the syslinux package are required by pxelinux.0 to support the menu configurations created by Cobbler. The RHN Satellite installer, install.pl, can be used to deploy Cobbler when a Satellite server is installed, but the cobbler-setup can also install Cobbler and enable tftp services post installation. The cobbler-sync command performs the additional step of deploying menu.c32 and pxelinux.0 to support menus in the x86 environment.
References Red Hat Network Satellite Deployment Guide • Chapter 5: Provisioning with Satellite
140
RH401-6-en-1-20110713
PXE Boot
Practice Exercise
Automating RHN Satellite Client Configuration Carefully perform the following steps. Ask your instructor if you have problems or questions. Use an activation key to register newly installed machines to your Red Hat Network Satellite Server. It should subscribe the systems to useful software channels and join the Example Servers system group. 1.
Create an activation key with a label of example-web. When clients are registered with this activation key, the following actions should be performed: • Subscribe to the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base software channel • Subscribe to the related Red Hat Network Tools and Example custom child software channels • Provide a provisioning entitlement • Subscribe to the Example Configs configuration channel • Deploy configuration files provided by the Example Configs configuration channel • Associate with the Example Servers system group
2.
Since signed packages will probably be deployed when the new systems are provisioned, the GPG keys used to verify their signatures need to be deployed as well. Import the GPG key used to verify custom packages built for Example, Inc. and the GPG key used to verify standard Red Hat released RPMS. These keys are found in /var/www/html/ pub/EXAMPLE-GPG-KEY and /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release respectively.
RH401-6-en-1-20110713
141
Chapter 9. Provisioning with PXE
Practice Exercise
Creating a Web Server Kickstart Profile Carefully perform the following steps. Ask your instructor if you have problems or questions. Create a kickstart profile to build a web server that is ready to use immediately after it is installed from bare metal. 1.
Create a kickstart profile labeled web-server that uses Red Hat Enterprise Linux 6 Server to install a new machine. This profile will be used for bare-metal installations without any use of virtualization. The most recent kickstart tree available should be used to perform the installation. The initial root password for systems built with this profile should be redhat.
2.
The kickstart profile should create three native disk partitions. The first partition should contain a 256MB ext3 file system mounted as /boot. A swap partition should be created 2048MB large. The final native disk partition should be a 17GB LVM physical volume. Create a volume group named vol0 that includes the 17GB physical volume. Two logical volumes should be created within the vol0 volume group. The first logical volume should be named home and it should be 512MB in size. It will contain the /home filesystem. The second logical volume should be named root and it should consume the rest of the unused storage in vol0. It will be used for the / filesystem. Choose the appropriate time zone for your locale. Systems in this organization have hardware clocks which keep time using UTC instead of local time. The kickstart should install the GPG keys used to verify package signatures for RPMS released from Red Hat and custom packages provided by Example, Inc.
3.
Systems built with this kickstart profile are web servers, but they are also used with graphical utilities and Subversion. Ensure the subversion RPM and the following package groups are installed: x11, basic-desktop, and web-server.
4.
Update the kickstart profile so systems built with this profile register with the Red Hat Network Satellite Server using the Example Web Server activation key.
5.
Create a post script in the kickstart profile that performs the following tasks: • Create a user named oliver with a password of password • Install the example RPM provided by the custom software channel • Update all system software to its most current release • Configure the web server to start at boot
142
RH401-6-en-1-20110713
PXE Boot
Practice Exercise
Set up the Provisioning Network Carefully perform the following steps. Ask your instructor if you have problems or questions. Before desktopX provides any network services, it must be configured to communicate with and act as a gateway for its backend network. Also configure the Cobbler component of Red Hat Network Satellite Server to provide tftp and pxelinux capabilities for provisioning. Make sure Cobbler is installed and functioning properly. 1.
Physically disconnect your client workstation, desktopY, from the classroom network. Cable desktopY so it is connected to the second NIC of desktopX. This can be accomplished with either cross-over cables or with a small switch with two patch cables. Your instructor should have provided you with all necessary hardware to accomplish this task.
2.
Configure the backend interface of desktopX to have a static IP address of 10.100.X.254/24. You will not be able to fully test the backend interface until you power up and configure desktopY. Do a preliminary test by pinging the interface address.
3.
Enable IPv4 packet forwarding on desktopX. Make sure this feature is persistent across reboots.
4.
The following diagram represents the configuration of your lab environment when you finish this sequence:
RH401 Student Network Configuration =================================== -----+-------------------- Classroom intranet | eth0 | 192.168.0.X ,---+---. | | desktopX.example.com (desktopX) | | `---+---' | eth1 | 10.100.X.254 | | eth0 | 10.100.X.1 ,---+---. | | station1.privateX.com (desktopY) | | `-------'
5.
When installing Red Hat Network Satellite Server, the installer asks if Cobbler should be used to provide provisioning services. If it isn't already installed, use the cobbler-setup command to install Cobbler and enable tftp services.
6.
Run cobbler sync as root to install the necessary files to support PXE network bootloading.
RH401-6-en-1-20110713
143
Chapter 9. Provisioning with PXE
7.
144
Confirm xinetd and tftp are configured to run at boot time and that xinetd is currently running.
RH401-6-en-1-20110713
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol, DHCP, allows a server to offer provisioning information to clients in a managed, automated fashion. DHCP is a superset of the BOOTP protocol; dhcpd has been designed to answer requests from BOOTP clients. BOOTP clients will retain their configuration information indefinitely; there is no notion of a lease in BOOTP. The DHCP server sends and receives on UDP port 67 and the client uses UDP port 68. When a client network interface is configured for a dynamic IP address, it sends a DHCPDISCOVER packet to the broadcast destination of 255.255.255.255. The broadcast packet will be handled by either a DHCP server connected to the local physical network or routers may be configured to forward the packet to a DHCP server on a different subnet. The client also sends its previous IP address in this packet. The first DHCP server to receive the broadcast packet from the client will respond by sending the client a DHCPOFFER packet based on its configuration. DHCPOFFER packets contain the DHCP server's IP address, the router, the IP address and subnet mask the client should use, and the lease time. The DHCP server may also offer other information such as NTP servers, DNS servers, timezones, domain names, etc. The client then broadcasts a DHCPREQUEST back to the server, requesting the IP address the DHCP server offered. At first glance this seems redundant, but there may be multiple DHCP servers on the subnet, or the router may be forwarding the DHCPOFFER to multiple networks. In this case the client's DHCPREQUEST packet includes the client's IP address and the IP address of the DHCP server the client received its address from. Once the DHCP server gets the DHCPREQUEST, it sends a DHCPACK acknowledging the client has exclusive rights to the client IP address until the lease time is up. The DHCP server may offer additional options such as filename and the IP address of next server for PXE boot. To configure a DHCP server, first use ip addr to verify that a BROADCAST address is specified in your network configuration. Initial DHCP requests in IPv4 are broadcast and not sent to a specific server. The dhcp package provides an IPv4 DHCP server and the dhcpv6 package provides an IPv6 DHCP server. We will concentrate on the installation and configuration of an IPv4 DHCP server in this course. The DHCP client packages, dhclient for IPv4 and dhcpv6_client for IPv6, are normally installed by default. /etc/sysconfig/dhcpd can be used to configure dhcpd by setting the DHCPDARGS variable. The following line in that file would cause dhcpd to listen on eth0 only: DHCPDARGS=eth0
Best Practice: Always run service dhcpd configtest after editing /etc/dhcpd.conf since configuration errors can prevent dhcpd from starting. The DHCP server is an SELinux restricted service when enforcing the default targeted policy on a RHEL5 system. The server uses a number of SELinux contexts for its various files as indicated in /etc/selinux/targeted/contexts/files/file_contexts.
RH401-6-en-1-20110713
145
Chapter 9. Provisioning with PXE
The dhcp package in Red Hat Enterprise Linux 5 installs with an empty /etc/dhcpd.conf having the correct SELinux context and a sample configuration in /usr/share/doc/dhcp-*. To start with the sample configuration while preserving the SELinux context, run: [root@host ~]# cp /usr/share/doc/dhcp-*/dhcpd.conf.sample /etc/dhcpd.conf
Gotcha: dhcpd will not start if /var/lib/dhcpd/dhcpd.leases is missing, has the wrong ownership/permissions, or has the wrong SELinux context. See the dhcpd.conf and dhcpoptions man pages for detailed descriptions of options. Run service dhcpd configtest to check syntax. There must be at least one subnet block defined in /etc/dhcpd.conf for the dhcpd service to start. The subnet must correspond with statically-configured interfaces.
Essential dhcpd.conf Configuration authoritative; ddns-update-style none; subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.254; option subnet-mask 255.255.255.0; option domain-name-servers 192.168.0.1; option time-offset -18000; # EST # DHCP clients range 192.168.0.1 192.168.0.100; default-lease-time 21600; # 6 hours max-lease-time 43200; # 12 hours }
One subnet section must be defined for each configured interface on the DHCP server. Override this requirement in /etc/sysconfig/dhcpd with the DHCPDARGS variable, which can contain a space-separated list of interfaces to which dhcpd should bind. Placing DHCPDARGS=eth0 in / etc/sysconfig/dhcpd would only require one subnet declaration, and that declaration would apply to eth0's network. ddns-update-style is the dynamic DNS update style. It should always be specified and may be one of ad-hoc, interim, or none. Using interim, the DHCP server will send the client host name to the DNS server. range versus range dynamic-bootp The range line determines the range of IP addresses the server will assign to DHCP clients only. Another option would be to specify range dynamic-bootp instead of range. Such a command would determine the range of IP addresses the server will pass to both DHCP and BOOTP clients. The difference between the two is that BOOTP clients do not relinquish their IP addresses. DHCP clients, on the other hand, recognize and use lease times in order to better manage the IP range. If a client does not ask for any particular lease length, the server will use the default-leasetime. The max-lease-time determines the maximum possible lease time. These time values are expressed in seconds and they determine the amount of time the DHCP server will reserve the IP address for the client. In a QA lab these lease times may be a few seconds--just enough
146
RH401-6-en-1-20110713
Reserved IP Addresses
time to run a few network tests on a certain machine. Having a small lease time would mean the DHCP server could rotate through the IP address range fairly quickly. In an office environment the lease times could be hours or days since the clients might rarely change.
Reserved IP Addresses authoritative; ddns-update-style none; subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.254; ...truncated... range 192.168.0.1 192.168.0.100; } host station151 { hardware ethernet 12:34:56:78:AB:CD; # this IP must be outside DHCP and BOOTP ranges fixed-address 192.168.0.151; }
The host declaration can bind a MAC address to an IP address - in essence giving it a static IP address. The entry after the host parameter (in this case station151) may be passed to the DNS server when using ddns-update-style interim. In the example host entry above, we assign a host name and IP address to a certain MAC address. If a DHCP client having the MAC address 12:34:56:78:AB:CD attempts to get an IP address from this DHCP server, the server will offer it an IP address of 192.168.0.151.
Offering Files via DHCP subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; ...truncated... # specify server and file locations next-server 192.168.0.254; # could be DNS name filename "pxelinux.0"; # always use quotes } host station151 { hardware ethernet 12:34:56:78:AB:CD; # this IP must be outside DHCP and BOOTP range fixed-address 192.168.0.151; }
This example adds two lines to the subnet stanza in order to offer it a pxelinux boot loader. If station151 is capable of PXE booting and it contacts the DHCP server via its 192.168.0.0/24 subnet NIC, station151 will use tftp to get the file pxelinux.0 from host 192.168.0.254. The server could also be identified with a DNS host name instead of an IP address.
RH401-6-en-1-20110713
147
Chapter 9. Provisioning with PXE
References /usr/share/doc/dhcp-*/replaceable>/README dhcpd.conf(5) and dhcp-options(5) man pages Red Hat Network Satellite Reference Guide • Section 11.1.2: Cobbler and DHCP
148
RH401-6-en-1-20110713
Reserved IP Addresses
Practice Exercise
Configure DHCP to Support PXE Carefully perform the following steps. Ask your instructor if you have problems or questions. Install a DHCP server that will issue IP addresses, both generally and based on MAC address, to your provisioning network. 1.
Install the dhcp package on desktopX.
2.
Use the /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point for the DHCP server. • Change the subnet to 10.100.X.0/255.255.255.0. • Change the router to the IP address of the backend network interface of your DHCP server. • Set the DNS server to 192.168.0.254. • Set the default DNS search domain to example.com. • Issue IP addresses in the range from 10.100.X.2 to 10.100.X.10. • Deploy the network boot loader to support PXE booting. Configure your DHCP service to only issue IP addresses on the Ethernet card attached to the backend subnet.
3.
In another terminal window or virtual console follow /var/log/messages. In your original shell start dhcpd and configure it to start at boot-time. PXE boot your client workstation. You may need to press a function key during the boot sequence to choose network boot. Observe /var/log/messages as well as the boot messages on desktopY. Record desktopY's MAC address for future reference:
4.
Use the MAC address of your second machine as recorded in /var/log/messages on desktopX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. The name of the client host will be station1.privateX.com. Restart the dhcpd service. PXE boot the client machine and verify that it gets the new address. It should also display the Cobbler PXE boot menu.
RH401-6-en-1-20110713
149
Chapter 9. Provisioning with PXE
Cobbler and Koan Cobbler Cobbler is a great tool for building and maintaining a network infrastructure that supports kickstart installations. Red Hat Network Satellite Server uses Cobbler to facilitate all types of provisioning: bare-metal, virtual machine, and reinstallation. Cobbler was written by Michael DeHaan for the purpose of taking many separate technologies used for provisioning and managing them with a single tool. Cobbler is used to manage distributions (distros), kickstart profiles (profiles), and system provisioning configurations (system). Distributions, or distros define the locations for the installation kernel, its initial ramdisk image, and other installer parameters. Each kickstart tree in a RHN Satellite Server defines a standard installer distribution and a distribution that works with Xen. Also when base channels are cloned, Satellite creates distributions for the installation trees used with the cloned channels. Cobbler profiles define the location of the kickstart file associated with the profile and the distribution to be used. They also contain other metadata such as RHN Satellite organization. When a Cobbler kickstart profile is associated with a provisioned virtual guests, fields within the profile define the virtual machine's characteristics such as number of virtual CPUs and memory size. When systems are provisioned, Cobbler creates a system definition that defines which kickstart profile should be used to build the system. Other information such as the installation media path and network settings are kept in the system definition. Note the media path in system definitions created by RHN Satellite contain a hashed pathname that expires. So you will need to refresh the system profile by using the Satellite web interface to initiate the kickstart (select the system then click on the Provisioning tab, then Kickstart sub-tab, then the Schedule tab). Cobbler provides a network boot infrastructure: • Installs and configures a TFTP server • Deploys and configures pxelinux • Links to RHN Satellite kickstart profiles • Does not implement DHCP services Cobbler can be executed from the shell on the system which hosts it, typically the Satellite Server. The cobbler command is immediately followed by the Cobbler sub-command to be executed. Options are specified last and some options are required for certain commands. Builtin help messages appear when the -h option is specified on a partial command line. The default configuration allows only root to successfully execute Cobbler commands. The cobbler aclsetup command controls Cobbler access for other users. The cobbler list command displays a list of all known distros, their associated kickstart profiles, and the system definitions which are configured to use those profiles. The cobbler report command produces a detailed list of the settings associated with each distro, profile, and system in that order. Cobbler also has distro, profile, and system subcommands. For example, the following command displays detailed information about the guest2:2:Example profile:
150
RH401-6-en-1-20110713
Provisioning with Cobbler
[root@host ~]# cobbler profile report --name=guest2:2:Example
Cobbler Installation Cobbler should be installed when a Red Hat Network Satellite Server will be used for provisioning. The RHN Satellite installer prompts and asks if Cobbler should be installed. When Cobbler is chosen, the tftp-server package and its dependencies are installed and configured to provide pxelinux support on the network. It generates the necessary pxelinux menus and configuration to provide network installation services. Sometimes a few adjustments have to be made to the server running RHN Satellite to support Cobbler. After Cobbler is installed, the cobbler check command should be used to checks its current operating environment. This command displays suggestions for making adjustments to get Cobbler to work. Some of the suggestions should be implemented but there may be others that are not relevant to a particular installation. Cobbler should be restarted and synchronized whenever its configuration file, /etc/cobbler/ settings, is modified: [root@host ~]# service cobblerd restart [root@host ~]# cobbler sync
Cobbler can be used to: • Inspect and modify its own configuration • Generate a custom installation ISO • Reprovision systems using kickstart • Control power management functions
Provisioning with Cobbler Changing a kickstart profile of a system allows for easy reprovisioning. The following command changes the kickstart profile of station3.example.com to the template used to install FTP servers: [root@host ~]# cobbler system edit --name=station3.example.com:2 --profile=ftpserver:2:Example --netboot-enabled=1
The :2 in the names above represent the organization ID number of the organization which created them. To begin the installation station3.example.com needs to be rebooted, then the changes will go into effect. When using Red Hat Network Satellite, Cobbler is typically used behind the scenes. Many of the provisioning adjustments made in the Satellite web interface make changes to Cobbler's profiles. For example, importing additional content using satellite-sync creates additional distros. Changing kickstart profiles for a system can be accomplished using a few mouse clicks. Cobbler provides a command-line interface to provisioning tasks. To PXE provision a system using cobbler, set the client system BIOS to boot from network first then the hard drive. Enable the Cobbler pxe_just_once global setting and use the netbootenabled flag on each system to control installation.
RH401-6-en-1-20110713
151
Chapter 9. Provisioning with PXE
Warning RHN Satellite uses Cobbler as a back-end provisioning engine. It should not be used as a standalone tool. Do not use Cobbler subcommands and features that are outside of the scope of RHN Satellite documentation.
The cobbler buildiso command creates a bootable ISO CD image for use with machines that don't have PXE support. Each ISO is customized to fit the current Cobbler configuration of the Satellite Server they are created on. Because of their custom nature, these images need to be rebuilt whenever additional kickstart profiles are created within the Satellite Server.
Koan Koan allows remote access to Cobbler. The $SNIPPET('koan_environment') macro expands to shell code that creates files on kickstarted machines which define a shell variable, COBBLER_SERVER. Its value is the host name of the Satellite Server used to provision the client and Koan uses this variable as the default Cobbler server to access. COBBLER_SERVER can be temporarily overridden by specifying the --server option when using the koan command. Koan can query Cobbler settings on a Red Hat Network Satellite Server. For example, the following command displays a list of distributions provided by Cobbler: [user@host ~]$ koan --list=distros --server=satellite.fqdn
The following command lists the kickstart profiles provided by the Satellite Server used to install the client machine: [user@host ~]$ koan --list=profiles
Koan can cause Cobbler to initiate a kickstart installation. This type of action requires root shell access. The following command changes Cobbler's configuration so the local client will be reinstalled when it is rebooted: [root@host ~]# koan --replace-self
Specifying the --profile option causes Koan to select a different kickstart profile than the current one for reinstalling a system. Koan can also be used to provision virtual guests. The following koan command installs a virtual guest on the current host according to the kickstart file specified by the --profile option: [root@host ~]# koan --virt --profile=virt_guest_profile
Koan can interact with Cobbler to update its configuration. Koan is provided by the koan RPM (rhn-tools channel)
152
RH401-6-en-1-20110713
Koan
References Red Hat Network Satellite Reference Guide • Chapter 11: Cobbler Red Hat Network Satellite Deployment Guide • Section 5.9: Advanced Topics cobbler(1) koan(1) man pages
RH401-6-en-1-20110713
153
Chapter 9. Provisioning with PXE
Practice Exercise
PXE Installation of a Web Server Carefully perform the following steps. Ask your instructor if you have problems or questions. Now that all the pieces are in place, kickstart a client system as a web server within the Example, Inc. organization. 1.
Delete all previous system profiles from the Satellite Server. This is required to free up all entitlements needed for the new web server that will be kickstarted.
2.
Power on or reboot the client machine and select PXE boot. How PXE boot is selected varies between various hardware vendors. Notice the Cobbler menu that appears has a new menu item: web-server:orgID:ExampleInc
Use the arrow keys and choose this menu item to begin the installation of your web server. 3.
Once the installation completes, confirm the new web server is built according to specification. If anything didn't work properly, ask your instructor for help and troubleshoot your RHN Satellite configurations.
4.
Completely automate the PXE installation of your web server. Delete the existing system profile to free up entitlements before you being the automated installation. Configure the system BIOS to PXE boot first then boot from the local hard drive. Create a Cobbler system profile for your system called station1 based on the machine's IP address. Configure Cobbler to PXE boot only once by default and use the netbootenabled flag within the system profile to control installation. After you install your system and confirm everything worked correctly, delete the station1 Cobbler system profile so it doesn't conflict with later lab exercises.
154
RH401-6-en-1-20110713
Koan
Personal Notes
RH401-6-en-1-20110713
155
Chapter 9. Provisioning with PXE
Unit Summary Provisioning Requirements In this section you learned how to: • Define components of bare metal provisioning . Tuning RHN Satellite for Provisioning In this section you learned how to: • Tune RHN Satellite for Provisioning . Dynamic Host Configuration Protocol In this section you learned how to: • Install and configure DHCP • Implement a bare metal install environment with DHCP . Cobbler and Koan In this section you learned how to: • Implement a bare metal install environment with Cobbler/Koan • Use Cobbler and Koan to support kickstart .
156
RH401-6-en-1-20110713
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
Chapter 10. RHN Virtual Machine Management
ONBOOT=yes
The BOOTPROTO directive in the example indicates the virtualization host should get its network assignments from DHCP. Static assignments can be specified instead with the IPADDR and NETMASK directives when BOOTPROTO is defined as static. After the ifcfg-br0 is created, modify the ifcfg-eth0 network interface file to look like the following: DEVICE=eth0 BRIDGE=br0 HWADDR=mac-address-of-eth0 ONBOOT=yes
Once these files are in place, use the service network restart command to apply your changes or reboot the system. The br0 bridge should be specified when virtual guests are created to allow them direct access to the external network.
References Red Hat Network Satellite Reference Guide • Section 10.1: Setting Up the Host System for Your Virtual Systems
160
RH401-6-en-1-20110713
Bridge Network Interface Configuration
Practice Exercise
Converting a Server to a Virtualization Host Before you begin... Your client machine, station1.privateX.com, will be transformed into a server that will host virtualization guest machines. Carefully perform the following steps. Ask your instructor if you have problems or questions. Example, Inc. has existing machines registered with their Red Hat Network Satellite Server. Virtualization is being introduced to their server room so existing hosts need to be converted into virtualization hosts running virtual guests. 1.
First the network needs to be configured to provide a bridge network interface for virtual guests. Disable the NetworkManager service to prevent network configuration files from automatic modifications: [root@station1 ~]# chkconfig NetworkManager off [root@station1 ~]# service NetworkManager stop
Create/modify the network configuration files on station1 to support a network bridge. / etc/sysconfig/network-scripts/ifcfg-br0 should contain the following lines: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp DELAY=0 ONBOOT=yes
Modify /etc/sysconfig/network-scripts/ifcfg-eth0 so it contains the following lines: DEVICE=eth0 BRIDGE=br0 HWADDR=mac-address-of-eth0 ONBOOT=yes
Once the files have been modified, restart the network service and confirm station1 has a working network with br0 bridge. 2.
Install additional software needed to support virtualization. Install the virtualization, virtualization-client, and virtualization-platform package groups. Once all the software is installed, reboot your client system.
3.
Copy the install-vserver script from the instructor's machine to your client system, station1, and execute it. It will use kickstart to install a virtual guest called vserver on the local machine. The script can be found at the following URL: ftp:// instructor.example.com/pub/materials/install-vserver.
RH401-6-en-1-20110713
161
Chapter 10. RHN Virtual Machine Management
Practice Exercise
Red Hat Network Registration of Virtual Machines Before you begin... A virtualization host (station1.privateX.com) running RHEL 6 registered to your RHN Satellite Server and a vserver virtual machine installed with RHEL 6 running as a guest. Carefully perform the following steps. Ask your instructor if you have problems or questions. In this sequence, you will register vserver with Red Hat Network under station1's entitlement. Note the first couple steps of this exercise can be completed on the Satellite server and virtualization host while vserver finishes installing. 1.
Log into your RHN Satellite using an account that can manage station1.privateX.com, and ensure it is entitled to Virtualization service and its software channel subscriptions include “RHN Tools for RHEL”.
2.
Log in as root on the virtualization host. Use yum to install the rhn-virtualizationhost and osad packages. Start the osad service and ensure it will start automatically at boot. This enables remote management of virtual machines from the RHN web interface.
3.
After the virtualization guest has finished installing, make sure the vserver domain is running. On the virtualization host run rhn_check and rhn-profile-sync as root.
4.
Log into the virtualization guest and download the bootstrap.sh script you completed in a previous lab from your Satellite Server. Use it to register the guest with your RHN Satellite Server.
5.
In the RHN web interface, select the Systems tab. You should see your newly-registered vserver virtual machine listed under its host name. Note the different system icon. Now click on your station1.privateX.com host name link, then on the system detail page find its Virtualization link/tab and click on that. You should see the list of the virtual machines running on station1 when you updated its RHN profile. If any of them are not registered with Red Hat Network, you will see “Unregistered System” instead of a host name for its profile name. Click on the hostname link for vserver (e.g. station9.privateX.com) to see its RHN profile.
162
RH401-6-en-1-20110713
Virtual Machine Provisioning
Virtual Machine Provisioning Provisioning Virtualization Hosts Using RHN • Prepare an activation key for registration • Subscribe to base + rhn-tools + vt channels as a minimum • Virtualization or Virtualization Platform add-on entitlement • Creation of kickstart profile • Important - virtualization type should be None for a KVM virtualization host, Xen Virtualized Host for Xen only • Incorporate activation key in previous step • Install osad and rhn-virtualization-host RPMS in %post • Create necessary network bridges in %post The best way to automate the provisioning of a virtualization host using Red Hat Network involves an activation key and a kickstart profile. The primary purpose of the activation key is to assign entitlements to the freshly installed virtualization host. It should subscribe to the base channel for Red Hat Enterprise Linux and the related RHN Tools child channel. The Virtualization or Virtualization Platform add-on entitlement can also be assigned to the new host using the activation key. This activation key can be modified or used with other activation keys to assign the new system to a system group for administration. Create a kickstart profile that uses the activation key described above. Although Xen Virtualized Host is presented as a Virtualization Type as part of the first step of creating the profile, select None when creating a KVM-based virtualization host. Xen Virtualized Host is used on Xen-based Red Hat Enterprise Linux 5 virtualization hosts and it enables capabilities and default selections in the kickstart profile that aid the building of a virtualization host, such as selecting the VT installation repository to be available during installation. Although the activation key subscribes the host to the RHN Tools child channel, the kickstart profile can perform that step as well. These channels can be selected in the kickstart profile by clicking the Kickstart Details tab then selecting the Operating System sub-tab. Note the kickstart profile child channel selection is overridden by activation keys, so consider this as a backup child channel assignment. Finally, create a kickstart %post script to install the osad and rhn-virtualization-host RPMS. This will permit administration of guest machines using the RHN web interface. You can't include these packages in the kickstart package list because the RHN Tools child channel isn't available during the installation of the core operating system. The relevant code in the %post section could be as follows: yum -y install rhn-virtualization-host osad chkconfig osad on
RH401-6-en-1-20110713
163
Chapter 10. RHN Virtual Machine Management
Provisioning Guest Machines Using RHN • Prepare an activation key for registration • Creation of kickstart profile • Important - virtualization type should be one of 3 types of guests: • KVM Virtualized Guest • Xen Fully-Virtualized Guest • Xen Para-Virtualized Guest • Specify virtual machine characteristics • Virtual memory and virtual CPU resources • Virtual disk space to be allocated • Network bridge interface • Use web interface to initiate guest kickstart Provisioning a virtualized guest is simpler than provisioning a virtualization host in some ways, but it requires more decisions in others. Registering with an activation key isn't really necessary, but is still useful for subscribing to other software channels and joining specific system groups. Create a kickstart profile and select one of the three virtual guest types when specifying the virtualization type. After kickstart location and the root password has been provided, tabs will appear that allow for further customization of the kickstart profile. Click the Kickstart Details tab then select the Details sub-tab. It is here you can change the virtualization type or determine virtual machine characteristics, such as: • virtual machine memory (default 512MB) • virtual CPUs (default 1) • virtual disk space (default 3GB) • network bridge The virtual disk will be allocated as a file on the virtualization host located in the /var/lib/ libvirt/images directory. The network bridge can be external facing, such as br0, or virbr0 (for a connection to the private, memory-based network provided by libvirt). Once all settings have been determined, use the web interface to initiate a kickstart of a guest machine. Navigate to the system profile of the virtualization host. Click on the Virtualization tab then select the Provisioning sub-tab. Click a radio button to select the guest kickstart profile to use and choose a unique name for the guest (it will serve as its Xen domain name). The final step is to schedule when the kickstart will occur.
Virtual Guest Deletion • Deleting a virtual guest requires a few steps:
164
RH401-6-en-1-20110713
Virtual Guest Deletion
• Shut down the virtual guest • Delete the virtual guest system profile from RHN • Remove the virtual guest configuration on the host • Remove the virtual storage image file Red Hat Network doesn't have a turn-key way to delete a virtual guest machine. Deleting a virtual guest involves a few steps to make sure it is thoroughly removed from the virtualization host and all disk space is reclaimed. First, shut down the guest machine. The Red Hat Network web interface can be used to shut down the virtual guest. Another option is to log into the virtualization host and use virsh destroy or virsh shutdown to shut down the guest VM. ssh can be used to log into the guest directly and use the shutdown. The next step is to delete the virtualization guest system profile from Red Hat Network. Log into RHN as a user who can administrate the virtual guest system, navigate and pull up the system profile of the virtual guest, then click the delete system button and confirm. Delete the domain configuration files from the virtualization host. Use the following command to remove the virtual system information out of the libvirt database: [root@host ~]# virsh undefine domainname
Finally, reclaim the disk space used as the disk image for the virtual guest. The following command should work on the virtualization host: [root@host ~]# rm -f /var/lib/libvirt/images/domainname
References Red Hat Network Satellite Reference Guide • Section 10.2: Setting Up Your Virtual Systems Red Hat Network Satellite Deployment Guide • Section 5.8.3: Virtualized Guest Provisioning
RH401-6-en-1-20110713
165
Chapter 10. RHN Virtual Machine Management
Practice Exercise
Provisioning a Virtualization Host Carefully perform the following steps. Ask your instructor if you have problems or questions. In previous exercises you converted an existing host to a virtualization host. Use RHN Satellite kickstart capabilities to provision a virtualization host from bare metal. 1.
Create a kickstart profile called kvm-host in your Satellite Server to build a virtualization host. The installing system should use the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the root password to redhat.
2.
Once the kvm-host kickstart profile is created, adjust the timezone to use the local timezone and installed systems use UTC in their hardware clocks. Automate installation of the standard Red Hat release GPG key. The @virtualization, @virtualizationclient, and @virtualization-platform package groups should be installed. Use the %post script of the kickstart file to install the rhn-virtualization-host and osad packages. Configure the osad service to start at boot time. Also provide some shell code to configure the network to use a bridged network interface.
3.
Use the Satellite Server to schedule station1.privateX.com to kickstart install itself using the kvm-host kickstart profile. The kickstart should be initiated immediately. While the client system installs, use Cobbler to determine the system profile name of the kickstarting system. Delete all other Cobbler system profiles then disable the netboot feature for the installing system.
166
RH401-6-en-1-20110713
Virtual Guest Deletion
Practice Exercise
Provisioning a Virtualized Guest Carefully perform the following steps. Ask your instructor if you have problems or questions. With the virtualization host built, now it is time to use Red Hat Network Satellite to provision the virtual guests running on the host. 1.
Create a kickstart profile called kvm-guest in your Satellite Server to build a virtual guest. The installing system should use the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the initial root password to redhat.
2.
Modify the virtual machine network configuration to use the br0 bridge interface of the virtualization host and send console messages to ttyS0. Adjust the timezone to use the local timezone and installed systems use UTC in their hardware clocks.
3.
Use the RHN Satellite to provision a virtual guest on station1.privateX.com. Schedule a guest system to install using the kvm-guest kickstart profile. The guest name should be named vserver and initiate the kickstart installation immediately.
4.
After the installation of the virtual guest completes, use the Satellite web interface to confirm that it has registered with the Satellite server.
RH401-6-en-1-20110713
167
Chapter 10. RHN Virtual Machine Management
Personal Notes
168
RH401-6-en-1-20110713
Virtual Guest Deletion
Unit Summary Virtual Host Configuration In this section you learned how to: • Manage RHN entitlements in a virtualized environment • Convert an existing Red Hat Enterprise Linux system into a KVM-based virtualization host • Create a network interface bridge . Virtual Machine Provisioning In this section you learned how to: • Use RHN Satellite to provision a KVM-based virtualization host • Use RHN Satellite to provision a virtual guest • Delete a virtual guest and reclaim its resources .
RH401-6-en-1-20110713
169
170
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
Chapter 11. RHN Satellite Server Administration
• Analyzed: db-control {gather-stats|report-stats} • Expanded: db-control extend TABLE • Shrunken: db-control shrink-segments
Database Backup and Restore The db_control backup location command saves the contents of the database to disk. It is a cold backup that requires the database to be offline during the backup, db_control does not stop the database automatically. -bash-3.2$ mkdir backup-YYYYMMDD -bash-3.2$ db-control stop Shutting down database... done. -bash-3.2$ db-control backup backup-YYYYMMDD Initiating cold backup of database rhnsat... /opt/apps/oracle/config/10.2.0/lkRHNSAT -> backup-YYYYMMDD/lkRHNSAT.gz ... done. ... Output omitted ... Full cold backup complete.
An alternate method for performing backups of the Satellite Server database includes the following steps: 1.
Stop the database
2.
Snapshot the /rhnsat partition
3.
Start the database
4. Backup /rhnsat and remove the snapshot when finished To restore a Satellite Server from backups, first reinstall the base operating system. Install the same version of the Satellite Server software. An answer file would help automate this process and make sure the server is built consistently. Once the Satellite Server finishes installing, do not go to the web page and create the Satellite Administrator account. Instead, stop the Satellite Server software and restore the filesystem backups for /rhnsat and / var/satellite. Make the most recent backup of the database available and restore the backup with the following command: -bash-3.2$ db-control restore path-to-backups
Restore the SSL key and certificate for the Satellite Server (more on that a little later) then start the RHN Satellite Server software. You can check the state of the backups by running db-control {examine|verify}.
174
RH401-6-en-1-20110713
Database Backup and Restore
References Red Hat Network Satellite Installation Guide • Section 8.4: Using RHN DB Control Red Hat Network Satellite Deployment Guide • Section 2.2.1: Backing up the Embedded Database • Section 2.2.3: Restoring the Embedded Database db-control(1) man page
RH401-6-en-1-20110713
175
Chapter 11. RHN Satellite Server Administration
Practice Exercise
RHN Satellite Embedded Database Maintenance Carefully perform the following steps. Ask your instructor if you have problems or questions. Perform basic RHN Satellite embedded database maintenance functions such as extending an internal table space and making a backup of your RHN Satellite database. 1.
Sometimes RHN Satellite embedded database performance can suffer when an internal table becomes full. Determine the current size and utilization of the UNDO_TBS table then extend it. Record both its original and new size and utilization below:
2.
Perform a backup of your Red Hat Network embedded database. Save the backup in a directory called rhn-sat-backup-YYYYMMDD below the home directory of the oracle account. How much disk space does the backup take?
3.
Confirm the integrity of the RHN Satellite embedded database backup you just created.
176
RH401-6-en-1-20110713
Satellite Server Management
Satellite Server Management RHN Certificate Management Entitlement certificates have to be updated for a couple of reasons. Each certificate issued by Red Hat has an expiration date so they must be renewed and reactivated. Also a new certificate will need to be activated when additional capabilities are purchased - perhaps more slots or different software entitlements are needed. Entitlement certificates are generated by Red Hat customer service. Check the expiration of your current certificate and be sure to call well ahead of the expiration when renewing. When a certificate expires there is a 7-day grace period, then the Satellite Server stops functioning until a new certificate is activated. Check the new certificate for correctness. It must match the version of Red Hat Network Satellite Server and always double check the number of system entitlements and software channel entitlements. Excess systems are unsubscribed by taskomatic and systems are unsubscribed based on taskomatic's queue which is random. When a system gets unsubscribed in this manner it loses its association with all channels including configuration channels. Once an entitlement because available it must be resubscribed manually which is a time consuming process. The tool of choice for RHN certificate management is rhn-satellite-activate. Use the -rhn-cert=PATH option to rhn-satellite-activate to specify the RHN certificate. This option verifies the integrity of the certificate, inserts it into the local Satellite Server database and then inserts it into the Red Hat database on RHN. The --disconnected option to rhnsatellite-activate prevents the remote insertion.
Disconnected to Connected Operation Many Red Hat consultants prefer to install Red Hat Network Satellite in disconnected mode then connect to hosted RHN once the server is running and has much of the software channel content loaded. This approach saves bandwidth and the installation process doesn't require Internet availability. First, the Satellite Server must be registered as a client of hosted Red Hat Network. It is very important that the server be registered with the RHN account that meets the following requirements: • it has an available RHN Satellite software entitlement • the Entitlement certificate is associated with it Next /etc/rhn/rhn.conf must be modified to point the Satellite Server back to hosted RHN's servers: server.satellite.rhn_parent = satellite.rhn.redhat.com
Finally, reactivate the Satellite Server with the RHN entitlement certificate using rhnsatellite-activate: # rhn-satellite-activate --rhn-cert=PATH-TO-CERT
RH401-6-en-1-20110713
177
Chapter 11. RHN Satellite Server Administration
SSL Certificate Management The RHN Satellite installer generates SSL keys and certificates. Original copies of CA and host certificates are stored in the /root/ssl-build directory. At the top-level directory is the certificate authority key and certificate. There is a subdirectory with the Satellite Server's host name that has the SSL key and certificate used by the RHN Satellite Apache daemon. Both directories also have source and binary RPMS used to deploy the keys. In /root/ssl-build the certificate authority certificate is store in a file called RHN-ORGTRUSTED-SSL-CERT. This file is embedded in an RPM called rhn-org-trusted-sslcert-1.0-1.noarch.rpm and both are published to RHN clients of the Satellite Server. RHNORG-PRIVATE-SSL-KEY is the certificate authority private key and it should be carefully guarded. /root/ssl-build/hostname contains the SSL host key and certificates used by the Satellite Server. The host certificate is signed by the CA in the top-level directory. The rhn-org-httpdssl-key-pair-hostname-1.0-1.noarch.rpm RPM contains all of the SSL files used by the Red Hat Network daemons that run on the Satellite Server. Here is the list of files provided by such an RPM: [root@host ssl-build]# rpm -qlp host/rhn-org-httpd-ssl-key-pair-host-1.0-1.noarch.rpm /etc/httpd/conf/ssl.crt/server.crt /etc/httpd/conf/ssl.csr/server.csr /etc/httpd/conf/ssl.key/server.key /etc/pki/spacewalk/jabberd/server.pem
The rhn-ssl-tool generates SSL keys/certs (and RPM) for Satellite use. Certificates are installed in ~/ssl-build. You must include either the --gen-server or the --gen-ca option to rhn-ssl-tool. When CA certificate changes it must be imported into Satellite database (rhn-ssl-dbstore).
Satellite Host Name Change Occasionally a Red Hat Network Satellite server's host name is changed to accommodate network changes. When the IP address changes, but there is no change in host name, existing SSL host certificates can be used without any changes. But when the host name changes, new SSL host certificates must be created to match the new Satellite host name. The spacewalk-hostname-rename command takes a single argument, the new IP address, and generates new SSL host certificates for the RHN Satellite server. This tool does not update any RHN Proxy or client system configurations. Their configurations will have to be updated to point to the new Satellite server host name.
178
RH401-6-en-1-20110713
Satellite Host Name Change
References Red Hat Network Satellite Installation Guide • Section 5.3: Managing the RHN Certificate with RHN Satellite Activate Red Hat Network Satellite Client Configuration Guide • Section 3.2: The RHN SSL Maintenance Tool rhn-satellite-activate(8), rhn-ssl-tool(1), rhn-ssl-dbstore(8), and satellite-hostname-rename(8) man pages
RH401-6-en-1-20110713
179
Chapter 11. RHN Satellite Server Administration
Practice Exercise
Activating a New Satellite Entitlement Certificate Carefully perform the following steps. Ask your instructor if you have problems or questions. There are a couple of reasons a new RHN Satellite entitlement certificate is issued to a Red Hat customer: expanded capabilities or an extension on the certificate expiration date. In this exercise you will activate a new Satellite entitlement certificate that will provide more capabilities. •
On the instructor's server there is a more robust RHN Satellite entitlement certificate available for your use. You can access the certificate using the following pathname on your Satellite Server: /misc/instructor/rh401-satellite/redhat-glsmaximum-5.4.cert. Reactivate your Satellite Server using this certificate. Log in as your Satellite Administrator, satadmin, and inspect the system and software entitlements available for deployment.
180
RH401-6-en-1-20110713
Software Channel Synchronization
Software Channel Synchronization Exporting Software Packages The rhn-satellite-exporter utility writes software channel information to the file system including packages, errata, kickstart trees, and metadata. Channel dumps created with this tool can be used to update disconnected Satellite servers. It can also be used to backup custom software channel content. Child channels cannot be exported by themselves. rhn-satellite-exporter will create an archive, but satellite-sync cannot use the child channel content by itself - it must be associated with a base channel. The following process properly exports a child channel so satellite-sync will use it: [root@host [root@host ... Output [root@host ... Output
~]# mkdir export-tmp ~]# rhn-satellite-exporter --step=short -d export-tmp -c base-channel-label omitted ... ~]# rhn-satellite-exporter -d export-tmp -c child-channel-label omitted ...
The --step=short option causes only the metadata to be dumped, no packages, no kickstart trees, no errata, just essentials. Useful rhn-satellite-exporter options: • --list-channels - shows available channels • --channel=LABEL - channel to include in dump • --dir=DIRECTORY - preexisting directory to put content into
Note The Inter-Satellite Sync (ISS) feature allows Satellite servers that are connected to each other to synchronize software channel content with each other. Normally there is a master/ slave relationship between servers, but bi-directional synchronization between two servers is also possible.
References rhn-satellite-exporter(8) man page Red Hat Network Satellite Installation Guide • Section 6.4: Inter-Satellite Sync • Section 6.5: Using Inter-Satellite Sync
RH401-6-en-1-20110713
181
Chapter 11. RHN Satellite Server Administration
Practice Exercise
Exporting Custom Child Software Channel Content Carefully perform the following steps. Ask your instructor if you have problems or questions. Backing up the RHN Satellite embedded database does not preserve custom software channel content. Use rhn-satellite-exporter to backup your custom software channel content. 1.
Log in as root on desktopX and display the list of software channels currently in your RHN Satellite Server. Take note of the labels of the channels you want to save and the names of their parent channel.
2.
Create a directory called custom-dump. Export the software channel content for the example-custom channel into custom-dump so it can be taken and imported into another disconnected Satellite Server.
3.
Confirm the channel content is usable with the satellite-sync command. Check carefully and be sure the example-custom channel appears in the output of satellitesync.
182
RH401-6-en-1-20110713
High Availability Options
High Availability Options Some companies demand high availability Red Hat Network services within their datacenters. The following solutions maintain high availability at differing expense levels in terms of cost and maintenance. One solution would be to implement RHN Satellite services on a high availability cluster. The services could be gracefully migrated to another node in the cluster during scheduled downtimes and would failover in the event of a crash. Larger corporations which have multiple Satellite servers can configure them in a horizontally tiered topology. Section 3.2 of the Red Hat Network Satellite 5.4 Installation Guide provides more details on this approach. It would require more maintenance to keep the content of the peers synchronized. Client machines would be configured to get updates from multiple servers. The servers are prioritized according to the order they appear in /etc/sysconfig/rhn/up2date: serverURL[comment]=Remote server URL serverURL=https://primary.satellite.fqdn/XMLRPC; https://backup.satellite.fqdn/XMLRPC
Another possible solution would be to clone a Satellite Server with an embedded database and keep a hot spare available. This process involves installing a second Satellite Server and synchronizing the database of the primary Satellite with the backup on a daily basis. Section 8.5 of the Red Hat Network Satellite 5.4 Installation Guide provides more details on this approach.
References Red Hat Network Satellite Installation Guide • Section 8.5: Cloning the Satellite with Embedded DB • Section 8.6: Establishing Redundant Satellites with Stand-Alone DB
RH401-6-en-1-20110713
183
Chapter 11. RHN Satellite Server Administration
Troubleshooting Satellite Server Issues Before we have seen that the rhn-satellite command is used to start and stop all of the daemons that implement Red Hat Network Satellite services. This tool can also display general status information about those daemons as well when passed the status argument. Additionally the status of the individual components of Red Hat Network can be checked using init scripts: [root@host ~]# service oracle status Oracle Net Listener (pid 2842) is running... Oracle DB instance rhnsat (pid 2854) is running... [root@host ~]# service httpd status httpd (pid 3514) is running... [root@host ~]# service taskomatic status RHN Taskomatic is running (3886).
Once a service has been identified as having problems, examining its log files is the next logical step in troubleshooting. Since RHN Satellite has many components, there are a variety of log files that could contain useful information. Debugging can be made more verbose by defining a debug value in /etc/rhn/rhn.conf. The possible values for debug range from 0 (disables most debug statements) to 6 (this is as verbose as it gets). Although some daemons write log messages in the system-wide log file, /var/log/messages, many RHN daemons have their own log files: • db-control operations and messages - /var/log/rhn/rhn_database.log • Messages related to push events to client systems - /var/log/rhn/osa-dispatcher.log • Log files for the Apache component - /var/log/httpd/* • Messages pertaining to Java support - /var/log/tomcat5/catalina.out • Messages concerning RHN scheduled tasks - /var/log/rhn/ rhn_taskomatic_daemon.log • Messages relevant to provisioning - /var/log/cobbler/* Red Hat Network also uses e-mail notifications. Make sure the traceback_mail variable in / etc/rhn/rhn.conf points to the e-mail address that should receive error message e-mails from the Satellite Server. E-mail messages that originate from the Satellite Server appear to come from the user
[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
Chapter 11. RHN Satellite Server Administration
Personal Notes
186
RH401-6-en-1-20110713
Troubleshooting Satellite Server Issues
Unit Summary RHN Satellite Database Management In this section you learned how to: • Maintain the RHN Satellite embedded database . Satellite Server Management In this section you learned how to: • Activate a new RHN Entitlement Certificate • Manage SSL certificates for secure communication • Connect a disconnected Satellite server to Hosted RHN . Software Channel Synchronization In this section you learned how to: • Export software channel content . High Availability Options In this section you learned how to: • Configure a hot-spare Satellite Server . Troubleshooting Satellite Server Issues In this section you learned how to: • Troubleshoot common Satellite server issues .
RH401-6-en-1-20110713
187
188
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
Chapter 12. RHN Application Programming Interface
Sample Python Script #!/usr/bin/python import xmlrpclib URL = "https://satellite.example.com/rpc/api" user = "rhn-username" pswd = "rhn-password" client = xmlrpclib.Server(URL, verbose=0) session = client.auth.login(user, pswd) list = client.user.list_assigned_system_groups(session, user) for group in list: print group.get('name') client.auth.logout(session)
The Python script above lists the system groups that the user rhn-username can manage. It connects to the Satellite Server and authenticates as rhn-username with the password of rhn-password. The listAssignedSystemGroups method in the user namespace is called to generate a list of system groups that rhn-username (passed as the variable user) can administrate. The for loop prints the name field of each of the values in the list of system groups. This script should work as long as rhn-username is a valid Red Hat Network user. Permissions aren't an issue since the user authenticating is accessing his own system group information. If this script were used to inspect the system groups of other users, it would have to authenticate as an Organization Administrator.
Sample Perl Script #!/usr/bin/perl use Frontier::Client; my $URL = 'https://satellite.example.com/rpc/api'; my $user = 'rhn-username'; my $pass = 'rhn-password'; my $client = new Frontier::Client(url => $URL); my $session = $client->call('auth.login', $user, $pass); my $systems = $client->call('system.listUserSystems', $session); foreach my $system (@$systems) { print $system->{'name'}."\n"; } $client->call('auth.logout', $session);
The Perl script above lists the systems the user named rhn-username can manage. It connects to the Satellite Server and authenticates as rhn-username with the password of rhnpassword. The listUserSystems method in the system namespace is called to generate a list of systems that rhn-username can administrate. The foreach loop prints the name field of each of the values in the list of systems.
192
RH401-6-en-1-20110713
Sample Perl Script
This script should work as long as rhn-username is a valid Red Hat Network user. Permissions aren't an issue since the user authenticating is accessing his own system group information. The listUserSystems method can take a second argument which would be a user's login name, but since it is omitted in this example it lists the systems managed by the authenticated RHN user. If this script were used to list the systems owned by other users, then it would have to authenticate as an Organization Administrator.
References Red Hat Network Satellite API Documentation • http://satellite.fqdn/rhn/apidoc/
RH401-6-en-1-20110713
193
Chapter 12. RHN Application Programming Interface
Practice Exercise
Getting Started with the Red Hat Network API Carefully perform the following steps. Ask your instructor if you have problems or questions. This exercise will introduce you to the Red Hat Network API. Modify two versions of a script written in Perl and Python so that they successfully query your RHN Satellite Server. 1.
There is a Perl script, list-users.pl, and a Python script, list-users.py, which list all the users within an Red Hat Network organization. The scripts can be found in the /misc/ instructor/materials/rhn-api directory. Log in as stan on desktopX, copy the scripts, and modify them so they will successfully query your Satellite Server and list the users in the “Example Inc.” organization. Optional - Use revision control software to log and manage the changes you make to your copies of the scripts.
2.
194
Modify one of your working scripts to authenticate as the Satellite Administrator. How does this affect the behavior of the script?
RH401-6-en-1-20110713
Sample Perl Script
Practice Exercise
Using the Red Hat API to Produce Reports Carefully perform the following steps. Ask your instructor if you have problems or questions. Modify one of the provided scripts to produce a useful report by using the Red Hat Network API to get more detailed information about the users from your Satellite Server. •
Write a script, list-user-roles.pl or list-user-roles.py, that lists all of the users within the Example Inc. organization. Print the following information about each user: their login name and the list of their RHN administrative roles. Copy one of your working scripts as a starting point for your new script. Optionally maintain your script with revision control software.
RH401-6-en-1-20110713
195
Chapter 12. RHN Application Programming Interface
RHN Satellite Reporting Tool Satellite Reporting Tool The Satellite Reporting Tool, spacewalk-report, is a command-line tool that produces a handful of CSV reports with information found in the RHN Satellite server database. This tool must be executed from a shell by root on the Satellite server. spacewalk-report has a useful --help option that lists the reports it provides when executed without an argument: [root@host ~]# spacewalk-report --help usage: /usr/bin/spacewalk-report [options] [report_name] ... Output omitted ... [root@host ~]# spacewalk-report errata-list entitlements inventory users-systems errata-systems users
This reporting tool queries the Satellite database directly and bypasses the RHN API which means it has access to all of the data stored in the database. Red Hat Network user authentication isn't required and the reports aren't confined to a single user or an organization's view of the data. Each report prints a header on the first line of output and the --listfields-info option provides a brief description of each of the fields: [root@host ~]# spacewalk-report inventory | head server_id,profile_name,hostname,ip_address,registered_by,... 1000010000,station139.example.com,station139.example.com,192.168.0.139,satadmin,... ... Output omitted ... [root@host ~]# spacewalk-report --list-fields-info inventory | head -n 5 server_id: System identifier profile_name: Profile name, as stored on server hostname: Hostname, as reported by the system ip_address: IP address, as reported by the system registered_by: User under which the system is registered
The Satellite Reporting Tool was a later feature added because of customer demand so it is not provided as part of the standard RHN Satellite 5.3.0 installation media. The spacewalkreports RPM is provided by the redhat-rhn-satellite software channel and can be installed after a Satellite server is installed and registered with Red Hat Network.
References spacewalk-report(8) man page
196
RH401-6-en-1-20110713
Criterion Test
Test
Criterion Test Exercise
Using the RHN API to Perform Satellite Administration Carefully perform the following steps. Ask your instructor if you have problems or questions. Write a couple Red Hat Network API scripts that perform RHN Satellite administration functions. 1.
Write two scripts that use the Red Hat Network API to administrate users. The userdisable.pl, or user-disable.py, script should deactivate a RHN user account. Its positive counterpart, user-enable.pl or user-enable.py, should reactivate an existing user account. Use a program variable for the RHN login to be enabled/disabled. These programs don't have to be fancy, they just have to be functional. There is no need to process command-line arguments or do extensive error checking. Optionally use revision control software to manage the changes you make to your new script.
2.
Use one of your scripts to disable the channelman account. Go into the RHN Satellite web interface and verify his account has been disabled. Execute the other script to reactivate his account and verify that channelman can log into your Satellite Server. Optionally commit your changes to Subversion once your scripts are working and debugged.
RH401-6-en-1-20110713
197
Chapter 12. RHN Application Programming Interface
Personal Notes
198
RH401-6-en-1-20110713
Criterion Test
Unit Summary Application Programming Interface Scripting In this section you learned how to: • Write simple reports with the Red Hat Network API • Use the RHN API to perform Satellite administration . RHN Satellite Reporting Tool In this section you learned how to: • Perform queries with the RHN Satellite Reporting Tool .
RH401-6-en-1-20110713
199
200
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
Practice Resequencing Exercise
Provisioning with a RHN Satellite Server Below are the steps you will take to deploy a provisioning Red Hat Network Satellite server. Take 5-10 minutes to prioritize and order the following steps. We will discuss them as a class before you begin to implement them. Configure desktopX to serve as a Subversion repository. Clone the RHEL 6 Server base channel and all of its child channels. Create a kickstart profile. Import the relevant Red Hat software channels into the Satellite server. Install desktopX with Red Hat Network Satellite software. Prepare software channel content for import into the RHN Satellite. Deploy DHCP on desktopX and configure it to support PXE. Build and sign a custom RPM package on desktopY. Configure desktopX as a routing gateway for the backend network. Create a RHN system group. Create an activation key to automate system registration. Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Provision the client system using PXE menu. Create RHN user accounts, assign appropriate roles, and allow them to administrate a common system group. Import GPG keys into the Satellite server for deployment. Create a Red Hat Network organization and assign it system and software subscriptions. Import the open source project code into the Subversion repository.
RH401-6-en-1-20110713
203
Chapter 13. Comprehensive Review
Test
Criterion Test Case Study
Red Hat Network Satellite Server Deployment Requirements The following are the specifics for setting up your Red Hat Network Satellite server and client machine. desktopX should already be installed with a minimal RHEL 5 installation and desktopY will serve as your client server and should be installed with RHEL 6 server. The requirements for this review are specified in more detail below. They aren't necessarily listed in the order they are to be performed. • Install desktopX as a Red Hat Network Satellite software. The materials you need to perform the installation can be found in the /misc/instructor/rh401-satellite directory on desktopX. The installation ISO is named satellite-embedded-oracle-5.4.0-20101025rhel-5-x86_64.iso. Activate the Satellite server using the certificate named redhatgls-maximum-5.4.cert. After the Satellite server is installed, create a satellite administrator account with a login of rhnsatadm and a password of redhat. • Prepare software channel content for import into the RHN Satellite. The content ISO's are in the rh401-satellite directory in a sub-directory called sat-rhel6-content. • Import the Red Hat software channels into the Satellite server that will support provisioning of RHEL 6 Servers. • Configure desktopX as a routing gateway for the backend network. The network addresses will be in the 10.100.X.0 subnet with a netmask of 255.255.255.0. The second network interface of desktopX should have a static address of 10.100.X.254. Ensure IPv4 packet forwarding is enabled persistently in the kernel. • Deploy DHCP on desktopX and configure it to support PXE provisioning. Determine the MAC address of desktopY and have DHCP consistently assign it the 10.100.X.7 IP address. Continue to use 192.168.0.254 for DNS services. • Build a custom RPM package on desktopY for the bubbles application. Consult the README and Makefile for information about building the package. Make sure both the binary executable and README are provided by the binary RPM that you create. The README should be classified as documentation by RPM. Generate a GPG key pair and sign the package. • Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Set the channel name to Custom Software with a label of custom-software. Specify the GPG key information you will use to verify the signature of RPMS you create.
204
RH401-6-en-1-20110713
• Create a Red Hat Network organization called Review Inc.. The organization administrator should log in as review with a password of redhat. Assign all available entitlements to this organization. • Create a RHN system group in the Review Inc. organization called Review Systems. Put some meaningful text in the Description field. • Configure desktopX to serve as a Subversion repository. The top-level URL to access the directory should be svn+ssh://desktopX/var/local/svn. Create a group called svnusers and set permissions on the repository that allows all users in that group to create new projects and modify files. Create a user called builder on both systems. This user should be a member of the svnusers group on desktopX. Also create ssh keys on desktopY and deploy them so builder can check in files to the repository without providing a password. • Create RHN user accounts, assign appropriate roles, and allow them to administrate systems in the Review Systems system group according to the following table: Login
swadmin
cfgadmin
Password
redhat
redhat
Roles
Channel Administrator
Configuration Administrator
• Import the open source project code for the "bubbles" program into the Subversion repository. The source code for this program can be found at the following URL: http://instructor/ pub/materials/bubbles-1.0.tar.gz. • Clone the RHEL 6 Server base channel and all of its child channels. Prefix the channel names with "Development" and the channel labels should have a "dev-" prefix. • Create an activation key to automate system registration. The key ID should be review-reg. It should register systems in the Review Inc. organization. Systems should join the Review Systems system group. They should also subscribe to cloned base software channel and rhntools and custom cloned channels. Also allow for configuration file provisioning and subscribe to the Review Configurations configuration channel. • Create a kickstart profile. It should register the provisioned system with the review-server activation key for Review Inc. It should install the web-server package group and update all available errata during its installation. The bubbles custom package should be installed and any available configuration files should be deployed. • Create a configuration channel called Review Configurations with a label of reviewconfigs. It provides /etc/issue which should contain the following text: Red Hat Enterprise Linux Server release 6.0 (Santiago) Kernel \r on an \m Review Inc.
• Import GPG keys into the Satellite server for deployment. Import the standard Red Hat key, RPM-GPG-KEY-redhat-release, and the GPG key used to verify custom packages.
RH401-6-en-1-20110713
205
Chapter 13. Comprehensive Review
• Provision the client system using PXE menu provided by Cobbler. Confirm that it installed properly and is properly configured. How would you address the case study described above? Take notes on your process in the space below and then implement it.
206
RH401-6-en-1-20110713
Personal Notes
RH401-6-en-1-20110713
207
208
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
Practice Resequencing Exercise
Enterprise Management Best Practices For each of the keywords below, write down the number of its definition from the list at the bottom. 2 5 1 3 4
Standardization Centralization Scalability Provisioning Automation
1.
Growth in capacity with minimal system administrator impact.
2.
Performing tasks with the same, well thought out method each and every time.
3.
The process taken to turn a system from bare-metal to installed and configured to meet the defined baseline. This should be as close to a fully automated process as possible.
4. Generally requires more upfront work. Investing time writing kickstart files allows one to install more systems simultaneously and more quickly than could be achieved by hand.
RH401-6-en-1-20110713
209
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
Criterion Test Exercise
Provisioning Preview Before you begin... You have two servers: desktopX and desktopY. Both servers are currently connected to the classroom network (192.168.0.0/24) which includes the instructor's machine, instructor.example.com. desktopX should be equipped with two Ethernet interfaces. Let's preview the capabilities and conveniences of a bare-metal provisioning environment. The instructor's machine, instructor.example.com, has been configured to provide bare-metal provisioning services. Your task is to configure both of your servers to PXE-boot and kickstart themselves.
210
RH401-6-en-1-20110713
1.
Reboot desktopX and go into the system BIOS configuration screens and make adjustments so desktopX will attempt to PXE boot from the network. Ask your instructor for help since this process can vary between various classroom environments.
2.
Reboot desktopX, but this time allow it to PXE boot from the network. If everything is properly configured, you should be presented with a PXE boot menu similar to the following:
Choose the “Install minimal RHEL 5 for RHN Satellite use” option without any arguments to begin the installation. While the installation begins, repeat these steps on your second server, desktopY. Be sure to choose the “Install minimal RHEL 5 for RHN Satellite use” option without any arguments to begin the installation.
RH401-6-en-1-20110713
211
Appendix A. Solutions
Installing a Red Hat Network Satellite Server Advantages of RHN Satellite Server Five major advantages of using RHN Satellite server include: 1.
Security
2.
Efficiency
3.
Control
4.
Customization
5.
Scalability
Practice Performance Checklist
Installing Red Hat Network Satellite Software Before you begin... You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopX. Install RHN Satellite software on your provisioning server, desktopX. Copy the sample RHN Entitlement Certificate, redhat-gls-minimal-5.4.cert, from the instructor's machine to root's home directory (~). This file can be found in the automounted /misc/instructor/rh401-satellite directory. [root@desktopX ~]# cd /misc/instructor/rh401-satellite [root@desktopX rh401-satellite]# cp redhat-gls-minimal-5.4.cert ~
Copy the satellite-embedded-*.iso image found on the instructor's machine to / tmp then mount it using a loopback device to /mnt. Don't execute /mnt/install.pl. We will use this script shortly. Instead list the contents of /mnt/install and look for a file called answers.txt. This file can be modified and used with install.pl to perform an unattended installation of the RHN Satellite Server software. Copy answers.txt to root's home directory. [root@desktopX rh401-satellite]# cp satellite-*.iso /tmp
212
RH401-6-en-1-20110713
[root@desktopX rh401-satellite]# mount -o loop /tmp/satellite-*.iso /mnt [root@desktopX rh401-satellite]# cp /mnt/install/answers.txt ~
Use your favorite text editor to modify root's answers.txt file. Find the following variable definitions and make all necessary adjustments: # RHN Satellite Server administrator admin-email =
[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
Appendix A. Solutions
Once the SSL certificate has been generated and imported into the Satellite Server, install.pl will restart the Satellite Server then exit. A URI will be displayed which you can use with a browser to complete the installation process. Launch a web browser and visit the URI displayed by install.pl: https:// desktopX.example.com. Examine the certificate offered to your browser and see if you recognize some of the values about the certificate subject and the issuer. Once you are satisfied with the contents of the certificate, accept it into your browser permanently. Create a RHN user called satadmin with a password of redhat. The e-mail address for this account should be
[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
Practice Performance Checklist
Preparing Channel Content for Import Before you begin... The RHN Satellite software installation on your desktopX machine should be completed. Channel content ISOs are available from the instructor's machine, instructor.example.com. Extract their contents into a common directory on your Satellite server, desktopX, so the channel content can be imported in a later lab exercise. The first step to take is make sure you have enough disk space to extract the content ISOs. They will require over 8 GB of space. Notify your instructor if you don't have enough room on your machine to extract them. [root@desktopX ~]# df -h
The content ISOs are published to the classroom in the /misc/instructor/rh401satellite/sat-rhel6-content/ directory. Mount the content ISOs using a loop interface to /mnt and copy the contents of both ISOs to a directory called /root/satrhel6-content/. [root@desktopX [root@desktopX [root@desktopX *-01.iso /mnt [root@desktopX [root@desktopX
~]# mkdir sat-rhel6-content ~]# cd /misc/instructor/rh401-satellite/sat-rhel6-content/ sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content sat-rhel6-content]# umount /mnt
Repeat the above steps for the second channel content ISO. [root@desktopX sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6*-02.iso /mnt [root@desktopX sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content [root@desktopX sat-rhel6-content]# umount /mnt
Practice Performance Checklist
Populating RHN Satellite with RHEL6 Software Before you begin... The RHN Satellite software installation on your desktopX machine should be completed and RHN channel content from both ISOs should be expanded into the /root/sat-rhel6-content/ directory on that server. Import the RHN base channel content for the Red Hat Enterprise Linux 6 Server software for 64bit x86 machines into your RHN Satellite server. The first software channel to be imported into a RHN Satellite 5.4 server takes much more time to import that subsequent channels. To conserve time, import the onerpm-channel base software channel published in the /misc/instructor/rh401satellite/one-rpm-channel.tar tar archive. Change into root's home directory
RH401-6-en-1-20110713
215
Appendix A. Solutions
on desktopX, extract the archive, import the one-rpm-channel software channel, then reboot your Satellite server before importing the Red Hat software channels. [root@desktopX sat-rhel6-content]# cd [root@desktopX ~]# tar xvf /misc/instructor/rh401-satellite/one-rpm-channel.tar one-rpm-channel/ one-rpm-channel/rpms/ ... Output omitted ... [root@desktopX ~]# satellite-sync -m one-rpm-channel --list-channels 09:24:17 Red Hat Network Satellite - file-system synchronization 09:24:17 mp: /root/one-rpm-channel 09:24:17 db: rhnsat/@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
Criterion Test Case Study
Deploying a RHN Satellite Server Before you begin... You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopY. Your department deploys and manages several servers running Red Hat Enterprise Linux. Your facility is an extremely secure site so you don't have access to hosted Red Hat Network services via the Internet. Your manager has invested in a Red Hat Network Satellite software to manage your systems. Your task is to install the RHN Satellite software on your desktopY machine and load it with the software channels needed to deploy Red Hat Enterprise Linux 6 Server systems. All of the material you need to install the system can be found in the /misc/instructor/rh401satellite directory. Use the redhat-gls-minimal-5.4.cert RHN Entitlement Certificate to activate the server. When you install the Satellite server, make sure the SSL CA certificate information is specified as follows: • Organization = Red Hat Inc. • Organization Unit = Training • City = your city
RH401-6-en-1-20110713
217
Appendix A. Solutions
• 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
Appendix A. Solutions
Red Hat Network Organization Practice Exercise
Organization Creation and Entitlement Before you begin... Students should have a functioning Red Hat Network Satellite Server, desktopX, installed with Red Hat Enterprise Linux Server base channel content loaded. Log in as the Satellite Administrator of your desktopX Satellite server. Create an organization called “Example Inc.” and assign it entitlements for provisioning and managing Red Hat Enterprise Linux Server systems. •
Create an organization in your Red Hat Network Satellite Server named “Example Inc.”. The Organization Administrator is Mr. Edward Example and he should log in as example with a password of redhat. E-mail for this account should be sent to
[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
Appendix A. Solutions
Log into the example account, select the Systems tab and click the System Groups menu item at the left. Click on the example servers link to bring up the system group details page then click the Admins tab. Check the check box by grouper and click the Update button to assign her group administrative privileges. This time when the system group access of grouper and normal is checked, grouper can see the system group but normal cannot. 3.
Log in as grouper and modify the group so normal can administer systems in that group. Log in as normal and confirm he has access to the group. Perform the same steps as in the task above, except check the box by normal instead. Log in as normal and confirm he has access to the group.
222
RH401-6-en-1-20110713
Using Subversion to Manage Changes
Using Subversion to Manage Changes Practice Exercise
Preparing the Subversion Repository and Users Before you begin... In this lab one of your two machines will be referred to as desktopX and will host the Subversion repository. This machine should be your RHN Satellite Server since you will reinstall desktopY to complete later labs. Your client machine, desktopY, will serve as the remote workstation of one of your Subversion users. Make sure the clocks on both of your machines are synchronized with each other. If you need to install packages, yum should already be configured on desktopX and desktopY. Your internal DNS servers have had some problems lately. The DNS administrators, Stan and Oliver, have been modifying configuration files in such a way they have been stepping on each others' changes. Your task is to deploy a Subversion server which will allow Stan and Oliver to work together and stop the configuration file conflicts. Build a Subversion repository on desktopX that will allow two users, oliver and stan, to create projects and work collaboratively. 1.
Reinstall desktopY with Red Hat Enterprise Linux 6 to prepare it for this and future lab exercises. PXE boot desktopY and select the “Install a standard RHEL 6 workstation” option.
2.
Log in as root on desktopX and install Subversion if necessary. Create a repo named /var/ local/svn on desktopX while desktopY reinstalls. After the installation finishes, check if Subversion is installed on desktopY. If not, then install it on desktopY also. First, log in as root on desktopX and perform the following commands: [root@desktopX ~]# yum install -y subversion [root@desktopX ~]# svnadmin create /var/local/svn
After desktopY finishes reinstalling, log in as root and repeat the above yum command. 3.
On desktopX, create a group called svnuser with a group ID of 60000. Modify the Subversion repository so all users in that group can create and modify projects. [root@desktopX ~]# groupadd -g 60000 svnuser [root@desktopX ~]# chgrp -R svnuser /var/local/svn [root@desktopX ~]# chmod -R g+w /var/local/svn/db
4.
Create user accounts for oliver and stan on both workstations. Assign their accounts the password of password on both systems. Make all necessary adjustments to their accounts to allow them to use Subversion from either host. Both users should be able to commit their changes to the Subversion repository without typing a password when they are logged into desktopY.
RH401-6-en-1-20110713
223
Appendix A. Solutions
Use the following commands on both systems to create accounts for oliver and stan and assign them passwords of password. Replace $user with each of their usernames: [root@desktopX ~]# useradd $user [root@desktopX ~]# echo password | passwd --stdin $user
Make all necessary adjustments to both their accounts to allow them to use Subversion from either host. Their accounts must be members of the svnuser group on the Subversion repository. Note the following command needs to be performed for both users on desktopX: [root@desktopX ~]# usermod -a -G svnuser $user
It is useful to define a default editor for Subversion so it can run the editor when changes are committed to the repository. Modify Oliver and Stan's ~/.bash_profile on both desktopX and desktopY so the EDITOR environment variable points to your preferred text editor. The following snippet of shell code should be defined in the ~/.bash_profile of both of their accounts on both systems, (note the example below uses vi, but you can use your preferred editor instead): export EDITOR=vi
Both users should be able to commit their changes to the Subversion repository without typing a password when they are logged into desktopY. Generate ssh keys for both users and propagate their public keys to desktopX, the Subversion repository. The solution below shows how to set the keys up for oliver. The same commands need to be performed for stan. [oliver@desktopY ~]$ ssh-keygen ... Output omitted ... [oliver@desktopY ~]$ ssh-copy-id desktopX.example.com ... Output omitted ...
Practice Exercise
Starting a New Project in Subversion Set up a new project in the Subversion repository for DNS configuration files. 1.
Log in as oliver on desktopX and create a subdirectory in Oliver's home directory called source. Create etc and var/named subdirectories below ~/source to provide a temporary DNS chroot hierarchy. [oliver@desktopX ~]$ mkdir -p source/{etc,var/named}
2.
224
Use anonymous FTP to download all the files in /pub/materials/namedfiles from instructor.example.com into ~/source. Move the files into the appropriate directories in the temporary tree. Do not change their names at this time.
RH401-6-en-1-20110713
Using Subversion to Manage Changes
[oliver@desktopX [oliver@desktopX [oliver@desktopX [oliver@desktopX
3.
~]$ cd source source]$ wget ftp://instructor.example.com/pub/materials/namedfiles/* source]$ mv named.conf etc/ source]$ mv *.zone var/named/
Have oliver create a new project called dnsfiles in the Subversion repository. The project should initially be populated with the files from his ~/source directory. If the group ownership and permissions assigned to the repository are correct, Oliver should be able to create the project since he is a member of the svnuser group. [oliver@desktopX source]$ cd ~ [oliver@desktopX ~]$ svn import source file:///var/local/svn/dnsfiles
When the text editor appears, insert “DNS configuration files” as the log message, save your changes, then quit the editor. You should see output similar to the following: Adding source/var Adding source/var/named Adding source/var/named/127.0.0.zone ... Output omitted ... Committed revision 1.
4.
Confirm the files are safely in the repository. Check the dnsfiles project out from the Subversion repository on desktopX and compare its contents with the files in ~/source. [oliver@desktopX ~]$ svn checkout file:///var/local/svn/dnsfiles
Compare the dnsfiles content with the files in ~/source. The only differences you should be the .svn subdirectories below dnsfiles. [oliver@desktopX ~]$ diff -r dnsfiles source Only in dnsfiles/etc: .svn ... Output omitted ...
5.
Remove the ~/source directory from Oliver's home directory once it is confirmed the DNS files are properly stored in the Subversion repository. [oliver@desktopX ~]$ rm -r source
Practice Exercise
Managing Changes with Subversion Create working directories and observe how Subversion manages concurrent changes by two users. 1.
Log in as oliver on desktopX. If the dnsfiles working directory doesn't exist, check out a working copy of the dnsfiles project below Oliver's home directory.
RH401-6-en-1-20110713
225
Appendix A. Solutions
If the dnsfiles working directory doesn't exist, run the following command: [oliver@desktopX ~]$ svn checkout file:///var/local/svn/dnsfiles
2.
Change to the top level directory of your Subversion working directory and modify etc/ named.conf. Find the comments that read “REPLACE FIX HERE WITH YOUR STATION NUMBER” and change all occurrences of the string “FIX” in the zone declarations to the last octet of desktopX's IP address. Note: This changes the files that DNS will try to reference. There are comments in the file noting that the actual files must be renamed for consistency. For now disregard those comments since you will fix the repository files to match the new names in a later lab exercise. Commit Oliver's changes with a log message of “Replaced FIX with station's IP.” [oliver@desktopX ~]$ cd ~/dnsfiles [oliver@desktopX dnsfiles]$ vi etc/named.conf [oliver@desktopX dnsfiles]$ svn commit -m "Replaced FIX with station's IP."
3.
In another window, log in as Stan on desktopY. Create a Subversion working directory in Stan's home directory and have Stan checkout a copy of the dnsfiles project. Examine named.conf. The changes made by Oliver should appear in that file. [stan@desktopY ~]$ svn checkout svn+ssh://desktopX.example.com/var/local/svn/dnsfiles [stan@desktopY ~]$ cd dnsfiles [stan@desktopY dnsfiles]$ less etc/named.conf
4.
As Stan, edit var/named/192.168.0.FIX.zone in the Subversion working directory and replace every occurrence of “FIX” with the last octet of desktopX's IP address. Be sure to update the serial number to YYYYMMDD00 using the digits of the current date. Commit Stan's changes with the same log message that Oliver used previously. [stan@desktopY dnsfiles]$ vi var/named/192.168.0.FIX.zone [stan@desktopY dnsfiles]$ svn commit -m "Replaced FIX with station's IP."
5.
On desktopX update Oliver's Subversion working directory so Stan's revisions are incorporated into Oliver's files. svn update without arguments checks if the current working directory is under control of Subversion. It uses information found in the .svn subdirectory to identify the repository and it recurses down the current directory looking for updates. It is best to change to the top level directory of the Subversion working directory to ensure all changes to the project are updated: [oliver@desktopX dnsfiles]$ svn status -u [oliver@desktopX dnsfiles]$ svn update [oliver@desktopX dnsfiles]$ less var/named/192.168.0.FIX.zone
226
RH401-6-en-1-20110713
Using Subversion to Manage Changes
Practice Exercise
Moving Files in a Subversion Project Previously Stan modified the contents of a file. Modify file names and observe how Subversion manages the changes. 1.
Using Stan's account on desktopY, use Subversion to change the name of the 192.168.0.FIX.zone file so “FIX” is replaced with the last octet of desktopX's IP address. Commit the changes into the Subversion repository with a descriptive log message. [stan@desktopY dnsfiles]$ cd var/named [stan@desktopY named]$ svn mv 192.168.0.FIX.zone 192.168.0.X.zone [stan@desktopY named]$ svn commit -m 'Moved 192.168.0.FIX.zone to 192.168.0.X.zone'
2.
Review the log messages of the 192.168.0.X.zone file. Rename the file domainFIX.example.com.zone so “FIX” is replaced with the last octet of desktopX's IP address. Make sure the changes are committed into the Subversion repository. [stan@desktopY named]$ svn log 192.168.0.X.zone [stan@desktopY named]$ svn mv domainFIX.example.com.zone domainX.example.com.zone [stan@desktopY named]$ svn commit -m 'Moved domainFIX.example.com.zone to domainX.example.com.zone'
3.
Examine Oliver's Subversion working directory on desktopX. Use Subversion to update his working files and see what happens. [oliver@desktopX [oliver@desktopX [oliver@desktopX [oliver@desktopX
dnsfiles]$ dnsfiles]$ dnsfiles]$ dnsfiles]$
ls -R svn status -u svn update ls -R
Practice Exercise
Subversion Conflict Resolution Observe how Subversion behaves when two users modify the same file, sometimes with conflicting changes. 1.
As Stan on desktopY, open domainX.example.com.zone in a text editor. Modify the SOA line of the file so all occurrences of “FIX” are changed to the last octet of desktopX's IP address. For example the student whose Satellite Server is station3.example.com would modify the line to look like the following: @ IN SOA desktop3.domain3.example.com.
root.desktop3.domain3.example.com. (
Save, exit, and commit the changes to the Subversion repository. [stan@desktopY named]$ vi domainX.example.com.zone [stan@desktopY named]$ svn commit -m 'Replaced FIX in SOA record.'
RH401-6-en-1-20110713
227
Appendix A. Solutions
2.
Without updating first, as Oliver on desktopX open domainX.example.com.zone in a text editor. Fix the NS resource record by replacing each “FIX” with the last octet of desktopX's IP address. Save, exit, and have Oliver commit the changes. This shouldn't require too much effort since Oliver's changes do not conflict with Stan's. [oliver@desktopX dnsfiles]$ cd var/named [oliver@desktopX named]$ vi domainX.example.com.zone [oliver@desktopX named]$ svn commit -m 'Replaced FIX in NS record.' Sending named/domainX.example.com.zone svn: Commit failed (details follow): svn: File '/dnsfiles/var/named/domainX.example.com.zone' is out of date
The commit above failed since Stan committed changes that Oliver hasn't downloaded yet. Download Stan's changes and try to save the changes to the Subversion repository again: [oliver@desktopX named]$ svn update G domainX.example.com.zone Updated to revision 6. [oliver@desktopX named]$ svn commit -m 'Replaced FIX in NS record.' Sending named/domainX.example.com.zone Transmitting file data . Committed revision 7.
3.
Have Stan on desktopY update his Subversion working directory and get Oliver's changes. As Stan, edit domainX.example.com.zone and change each “FIX” in the MX line to the last octet of desktopX's IP address. Update the serial number with the current date followed by a two digit sequence number. Commit Stan's changes to the Subversion repository. [stan@desktopY named]$ svn update U domainX.example.com.zone Updated to revision 7. [stan@desktopY named]$ vi domainX.example.com.zone [stan@desktopY named]$ svn commit -m 'Replaced FIX in MX record.' Sending named/domainX.example.com.zone Transmitting file data . Committed revision 8.
4.
As Oliver on desktopX, make the same changes that Stan made but also change the MX record priority to 15. Attempt to commit your changes. This will fail since Oliver's Subversion working directory is not updated. Also update the zone file serial number to be greater than the previous value. Commit Oliver's changes into the repository since his changes are more complete than Stan's changes. [oliver@desktopX named]$ vi domainX.example.com.zone
For instance, if desktop3 were your desktopX, change the line in domain3.example.com.zone to the following:
domain3.example.com.
228
IN MX
15
station3.domain3.example.com.
RH401-6-en-1-20110713
Using Subversion to Manage Changes
Once you have double checked your changes, commit them into the Subversion repository: [oliver@desktopX named]$ svn commit -m 'Fixed MX priority.' Sending named/domainX.example.com.zone svn: Commit failed (details follow): svn: File '/dnsfiles/var/named/domainX.example.com.zone' is out of date
The command above failed since Oliver's Subversion working directory did not include the most recent changes. Update Oliver's Subversion working directory. When a conflict occurs, a .mine file and other version files are created when the update Subversion command is issued. Commit Oliver's changes into the repository since his changes are more complete than Stan's. One way to do this is to accept the changes in the domainX.example.com.zone.mine file: [oliver@desktopX named]$ svn update Conflict discovered in 'domainX.example.com.zone'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options:
At this point, select 'p' to postpone the conflict resolution. This will allow you to view the different versions of this file and compare them. After you see the further output below, use mv and svn resolve to resolve the conflict and commit your changes: C domainX.example.com.zone Updated to revision 8. Summary of conflicts: Text conflicts: 1 [oliver@desktopX named]$ mv domainX.example.com.zone.mine domainX.example.com.zone [oliver@desktopX named]$ svn resolved domainX.example.com.zone Resolved conflicted state of 'domainX.example.com.zone' [oliver@desktopX named]$ svn commit -m 'Fixed MX priority.' Sending named/domainX.example.com.zone Transmitting file data . Committed revision 9.
5.
As either Oliver or Stan, update the remaining resource records in domainX.example.com.zone that contain “FIX” with desktopX's number. Update the serial numbers in the .zone zone files. Commit the changes into the Subversion repository. [stan@desktopY named]$ svn update [stan@desktopY named]$ vi domainX.example.com.zone [stan@desktopY named]$ svn commit -m 'Replaced remaining FIXs with the desktop number.'
RH401-6-en-1-20110713
229
Appendix A. Solutions
Red Hat Network Client Configuration Practice Quiz
RHN Registration Steps List the four steps (in order) that are taken when a client workstation registers with a RHN Satellite server. 1.
Update Red Hat Network software tools
2.
Point to relevant Red Hat Network server
3.
Install SSL CA certificate (Satellite/Proxy only)
4.
Register the RHN client system: authenticate as valid Red Hat Network user, or register with an activation key
Practice Performance Checklist
Graphical Red Hat Network Registration You will register a system with a Red Hat Network Satellite using rhn_register in a graphical environment. Since SSL encryption will be used, the organization CA certificate will have to be located and used when registering the client system. Your client workstation, desktopY.example.com, should already be installed to provide a graphical environment. The classroom installation configures yum to point to the instructor's server for additional RPMS. Remove the /etc/yum.repos.d/ dvd.repo configuration file and reset yum by executing the following command as root: [root@desktopY ~]# yum clean all [root@desktopY ~]# rm /etc/yum.repos.d/dvd.repo
Browse http://desktopX.example.com/pub and locate the CA certificate for the local organization provided by the Satellite Server. Download the CA certificate to the / tmp directory on desktopY. [root@desktopY ~]# wget http://desktopX/pub/RHN-ORG-TRUSTED-SSL-CERT -P /tmp
Log in as root on desktopX and monitor your Satellite server's Apache log files. Use tail -f to monitor them continuously. [root@desktopX ~]# tail -f /var/log/httpd/*
Open a terminal window on desktopY and execute rhn_register so it displays a graphical dialog box. Configure the client to use the Satellite Server, desktopX.example.com, for software updates. Use the SSL certificate you previously
230
RH401-6-en-1-20110713
Using Subversion to Manage Changes
downloaded and authenticate as the Red Hat Network user normal. Once the client is configured, use yum repolist to verify it is talking with the Satellite Server. [root@desktopY ~]# rhn_register
After reading the introductory screen, click the Forward button to advance. Select the radio button that indicates you have access to a RHN Satellite Server. The Location box will become active. Type the URL for desktopX in that box: https:// desktopX.example.com. Click the Forward button to advance. Select the radio button indicating you have an SSL certificate. Browse and locate the file in the /tmp directory of your local filesystem. Click the Forward button. rhn_register will ask for Red Hat Network authentication. Enter the login normal and the password redhat. Click Forward once the information is filled in. On the next screen, take the default values for the system name and the profile data. Click Forward again. rhn_register should contact the Satellite Server and send profile information to the server. Click Forward then Finish to complete the registration and exit. [root@desktopY ~]# yum repolist Loaded plugins: refresh-packagekit, rhnplugin repo id repo name rhel-x86_64-server-6 Red Hat Enterprise Linux Server ... repolist: 3,583
status 3,583
Use a web browser to log into the Satellite server web user interface as normal and see if the newly registered system shows up in the system list. Do the same for the Red Hat Network user grouper. Finally log in as the Organization Administrator, example, and see if the client shows up in his system list. The normal and grouper users are unable to see the new system because it is not associated with a system group they can view or administer. It is interesting that normal cannot see a system that was registered using his login and password. As the Organization Administrator, example, see if the client shows up in his system list under the Systems tab. The new system should be visible to this account.
Practice Performance Checklist
Text-based Red Hat Network Registration Register a system with a Red Hat Network Satellite using rhn_register in a text-based environment. You should already have the CA certificate copied to the filesystem on the client machine. Log into a text-based virtual console (Ctrl+Alt+F2) as root on desktopY and execute rhn_register to re-register your client with your Satellite server. When rhn_register asks for RHN authentication information, provide the login of normal with the password redhat.
RH401-6-en-1-20110713
231
Appendix A. Solutions
When you re-register your client with your Satellite server, it will print a warning: “System Software Updates already setup.” Disregard the warning and select Yes to continue. After rhn_register asks for RHN authentication information, select Next to continue. Accept the default values for profile name and other prompts. After the system information is sent to the Satellite server, review the system subscription details. You should see the software base channel, rhel-x86_64server-6, on the screen. Select OK then select Finish - the client registration is complete. Log into the Satellite server web interface as example. There should be two system profiles labeled desktopY.example.com.
Practice Exercise
Automating Registration with Activation Keys The previous exercises demonstrated how to register a machine with a Red Hat Network Satellite Server using interactive utilities. Automate the registration process by creating an activation key that registers with the Example RHN organization and use it to re-register your client. 1.
Log into your Satellite server as example and create an activation key named exampleservers. It should have a description of “Example Servers”, not have a usage limit, and subscribe the client to the default RHN Satellite base channel for the system being installed. This activation key should not consume any add-on entitlements and do not use it as the universal default. All systems registered with this activation key should automatically join the example systems system group. Log into the Satellite Server web interface as the Organization Administrator, example, since this is the only user in the organization who has the privileges needed to create an activation key. Another option would be to create a new user with the role of an Activation Key Administrator or promote an existing user into that role. Select the Systems tab then select Activation Keys from the menu at the left. Click on the create new key link in the upper right-hand corner of the window. Provide the following values in the fields of the dialog window that appears:
232
Field
Value
Description
Example Servers
Key (*)
orgID-example-servers
Usage
leave empty
Base Channel
Leave as RHN Satellite Default
Add On Entitlements
Leave everything unchecked
Universal Default
Leave unchecked
RH401-6-en-1-20110713
Using Subversion to Manage Changes
* - Record the organization ID number prefix (orgID) provided by the Satellite Server. This prefix associates the system being registered with a specific RHN organization. Click the Create Activation Key button once you confirm the form is filled out correctly. Click the Groups tab, then click the Join sub-tab and click the check box to select example servers. Click the Join Selected Groups button at the bottom of the screen to confirm the selection. 2.
Log in as root on the client, desktopY.example.com, and use rhnreg_ks to register your system using the activation key you just created. If the registration doesn't work immediately, diagnose what the problem is and fix it. The Satellite Server host name and information about the CA certificate already have useful default values. Normally they would have to be specified, but the previous registrations modified /etc/sysconfig/rhn/up2date so it points to valid values so the defaults can be taken. Be sure to include the organization ID prefix specified by the Satellite Server when the key was created. [root@desktopY ~]# rhnreg_ks --force --activationkey=orgID-example-servers
The two previous registrations consumed all of your subscriptions. One of the two system profiles needs to be deleted, but we might as well delete both entries. Log into the Satellite Server as example and select the Systems tab. Get the list of system profiles then click the profile name of the system you want to delete. Click the delete system button at the upper right-hand corner of the window then confirm the request by clicking the Delete Profile button. Repeat this process with the other system profile. Try the rhnreg_ks command again. This time it should work. 3.
Check the system profile of your client system in the Satellite Server. Is it a member of the example servers system group? If not, make the necessary adjustments to your activation key and re-register the client again. When you are finished with this exercise, delete all of the system profiles in the Satellite Server.
Practice Exercise
Registering Clients with a Bootstrap Script Red Hat Network Satellite software can create a template shell script, called a bootstrap script, that can register a client system with the Satellite server. Customize and use a bootstrap script to register a freshly installed system with your Satellite server. 1.
Reinstall your client workstation, desktopY, with a minimal footprint installation. Initiate a PXE boot and choose the “Install a minimal RHEL 6 installation” option without any arguments to begin the installation. While desktopY is installing, continue to the next step.
2.
A Satellite Server provides bootstrap scripts to all of its clients, not just to a specific organization, so they must be created and managed by the Satellite Administrator.
RH401-6-en-1-20110713
233
Appendix A. Solutions
While the client workstation installs, log in as the Satellite Administrator, satadmin, and in the web interface create a bootstrap script template as a starting point. The script should enable SSL and client GPG checking. It should not enable remote configuration and remote commands. These options will be introduced later in the course. Optional - Use Subversion to manage the changes you make to the bootstrap script you develop. Create a new Subversion project and check in the original version before you make any changes. Select the Admin tab then click the RHN Satellite Configuration menu option at the left. Click the Bootstrap Script sub-menu option. Fill in the form that appears with the following values: Field
Value
RHN Satellite server hostname
Confirm it is desktopX.example.com
SSL cert location
Confirm the pathname to your local CA certificate
Enable SSL
check
Enable Client GPG checking
check
Enable Remote Configuration
uncheck
Enable Remote Commands
uncheck
Leave the client HTTP proxy information blank since it doesn't apply. Click the Update button to confirm and accept your changes. Optional - To put the bootstrap script under control of Subversion, create a project called “bootstrap” that manages all of the files under the bootstrap directory. [root@desktopX ~]# cd /var/www/html/pub [root@desktopX pub]# svn import bootstrap -m 'Bootstrap scripts' file:///var/local/ svn/bootstrap Adding bootstrap/bootstrap.sh ... Output omitted ... [root@desktopX pub]# rm -rf bootstrap [root@desktopX pub]# svn co file:///var/local/svn/bootstrap A bootstrap/bootstrap.sh ... Output omitted ...
3.
Edit your bootstrap script on your Satellite Server. Disable the exit 1 line and modify the ACTIVATION_KEYS shell variable to point to the activation key you created earlier in this lab. [root@desktopX pub]# cd /var/www/html/pub/bootstrap [root@desktopX bootstrap]# vi bootstrap.sh
echo "the exit below)" echo #exit 1 # can be edited, but probably correct (unless created during initial
234
RH401-6-en-1-20110713
Using Subversion to Manage Changes
# install): # NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine. ACTIVATION_KEYS=orgID-example-servers
Optional - Commit your changes into Subversion once you are satisfied with them. [root@desktopX bootstrap]# svn commit -m 'Enabled script and added act key.' Sending bootstrap.sh Transmitting file data . Committed revision 14.
4.
Once the client machine has finished installing, log in as root, download the bootstrap script, and execute it manually. Normally this step would be performed in the %post section of a kickstart installation for full automation. Sign into the Satellite Server web interface as normal and confirm the system is registered and belongs to the example-servers system group. [root@desktopY ~]# wget http://desktopX/pub/bootstrap/bootstrap.sh [root@desktopY ~]# bash bootstrap.sh
RH401-6-en-1-20110713
235
Appendix A. Solutions
Red Hat Network Software Management Practice Exercise
Custom Software Channel Administration Create Linux and RHN Satellite accounts for the responsible person who is in charge of managing custom channel content. Create a GPG key for signing trusted third-party packages. Once the pieces are in place, create a custom software channel for Example, Inc. third-party software packages. 1.
Create Linux and RHN Satellite accounts on desktopX.example.com for Charles Channelman, the person responsible for managing software channels on the Satellite Server. The login/user name for his accounts should be channelman with passwords of redhat. His Red Hat Network account on the Satellite Server should permit him to manage software channels and the systems in the example servers system group. [root@desktopX ~]# useradd -c 'Charles Channelman' channelman [root@desktopX ~]# echo redhat | passwd --stdin channelman
Create a Red Hat Network account for Charles on the Satellite Server. Log into Satellite web UI as example, the Organization Administrator. Select the Users tab then click the create new user link. Fill in the form that appears with the following values: Field
Value
Desired Login
channelman
Desired Password
redhat
First, Last Name
Mr. Charles Channelman
E-mail
[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
Using Subversion to Manage Changes
... Output Omitted ... Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 5 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Enter Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = 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
Appendix A. Solutions
3.
Create a custom child software channel named “Example custom” with a label of examplecustom and configure it to advertise Charles Channelman's GPG key for verifying package signatures. It should be a child channel of the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) base software channel. Log into Satellite web UI as channelman. Choose the Channels top-level tab, select Manage Software Channels from the menu at the left, then click the create new channel link. Fill out the form that appears with the following values: Field
Value
Channel Name
Example custom
Channel Label
example-custom
Parent Channel
Red Hat Enterprise Linux Server (v.6 for 64bit x86_64)
Parent Channel Architecture
x86_64
Yum Repository Checksum Type
sha256
Channel Summary
Example third-party software
Channel Description
Example third-party software
Maintainer Name
Charles Channelman (not required)
Email Address
[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
Using Subversion to Manage Changes
... Output omitted ... 19:29:05 19:29:05 Retrieving / parsing channel-families data 19:29:05 channel-families data complete 19:29:05 19:29:05 Retrieving / parsing channel data 19:29:05 p = previously imported/synced channel 19:29:05 . = channel not yet imported/synced 19:29:05 base-channels: 19:29:05 . rhel-x86_64-client-6 2911 19:29:05 p rhel-x86_64-server-6 3583 ... Output omitted ... 19:29:05 rhel-x86_64-server-6: 19:29:05 . rhel-x86_64-server-fastrack-6 0 ... Output omitted ... 19:29:05 . rhn-tools-rhel-x86_64-server-6 21 ... Output omitted ... [root@desktopX ~]# satellite-sync -m /root/sat-rhel6-content -c rhn-tools-rhel-x86_64server-6
Practice Performance Checklist
Loading Third-party Content into RHN Satellite As channelman, take a third-party RPM provided by the instructor, sign it, and import it into the RHN Satellite Server and associate it with the example-custom software channel. Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the example-1.0-1.noarch.rpm RPM from /misc/instructor/RPMS to Charles' home directory, and sign it with his GPG key. [channelman@desktopX ~]$ cp /misc/instructor/RPMS/example-1.0-1.* ~ [channelman@desktopX ~]$ echo '%_gpg_name GPG-key-ID' > ~/.rpmmacros [channelman@desktopX ~]$ rpm --resign example-1.0-1.noarch.rpm Enter pass phrase: redhat Pass phrase is good. example-1.0-1.noarch.rpm: gpg: WARNING: standard input reopened gpg: WARNING: standard input reopened
Import the RPM into the Satellite Server so it is associated with the example-custom software channel. [channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom example-1.0-1.noarch.rpm Red Hat Network username: channelman Red Hat Network password: redhat
RH401-6-en-1-20110713
239
Appendix A. Solutions
Practice Performance Checklist
Subscribing to a Custom Channel Associate your client system, desktopY.example.com, with your custom software channel and install the example RPM on the client host. Subscribe your client system to the example-custom custom software channel. Login as a RHN user who can administer the client system, either channelman or normal will do. Select the Systems top-level tab then select Systems from the menu at the left. Select the link to the client system to access its Details page. Click the Software tab then the Software Channels sub-tab. Check the check-box by Example custom in the Software Channels Subscriptions then click the Change Subscriptions button to confirm your change. Import the GPG key used to sign the packages provided by the custom channel into the RPM database on the client system. Install the example RPM on the client machine using the yum command. Log in as root on desktopY and execute the following commands: [root@desktopY ~]# rpm --import http://desktopX/pub/EXAMPLE-GPG-KEY [root@desktopY ~]# yum repolist Loaded plugins: refresh-packagekit, rhnplugin repo id repo name status example-custom Example custom 1 rhel-x86_64-server-6 Red Hat Enterprise Linux Server ... 3,583 repolist: 3,584 [root@desktopY ~]# yum install -y example
Warnings will be displayed when the RPM installs because some of the files in the RPM have broken ownerships.
Practice Performance Checklist
Managing Updates with Cloned Channels Create clones of standard Red Hat channels and custom channels to control how software updates are rolled out to client systems. Create clones of standard Red Hat software channels (both base and child channels) and the custom software channel in your Satellite Server. These channels will be “Production” versions of their original counterparts so assign them labels identical to the original channels with a “prod-” prefix. Use the default values provided for the access controls of the cloned channels. First, clone the base channel that is the parent of all the other channels. Log in to the Satellite Server as the Channel Administrator, channelman. Click the Channels tab then select the Manage Software Channels menu item from the left. Click the clone channel link in the upper right-hand corner of the frame. Fill in the form that appears with the following values:
240
RH401-6-en-1-20110713
Using Subversion to Manage Changes
Field
Value
Clone From
Select Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64)
Clone
Select Original state
Click the Create Channel button. Another form will appear requiring additional information. Fill it in with the following values: Field
Value
Channel Name
Production Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64)
Channel Label
prod-rhel-x86_64-server-6
Leave the remaining fields with their default values then click the Create Channel button to complete the creation of the cloned base channel. Now the child channels must be cloned. Click the Channels tab then select the Manage Software Channels menu item from the left. Click the clone channel link in the upper right-hand corner of the frame. Fill in the form that appears with the following values: Field
Value
Clone From
Select RHN Tools for RHEL (v.6 for 64-bit x86_64)
Clone
Select Current state
Click the Create Channel button. Another form will appear requiring additional information. Fill it in with the following values: Field
Value
Parent Channel
Select Production Red Hat Enterprise Linux (v.6 for 64bit x86_64)
Channel Name
Production RHN Tools for RHEL (v. 6 for 64-bit x86_64)
Channel Label
prod-rhn-tools-rhel-x86_64server-6
Leave the remaining fields with their default values then click the Create Channel button to complete the creation of the cloned child channel. Repeat the same process for the Example custom child channel. Change the subscriptions of your client machine, desktopY, so it subscribes to the new cloned channels. Include “production” versions of the base channel and the Example custom child channel.
RH401-6-en-1-20110713
241
Appendix A. Solutions
Remove, then reinstall, the example RPM and confirm it comes from one of the cloned channels just created. Pull up the client system profile by selecting the Systems top-level tab, select Systems from the menu at the left, then click the client host name link. Select the Software tab then the Software Channels sub-tab. In the Base Software Channel frame, highlight the Production Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel and click Confirm. If a warning displays, click Modify Base Software Channel anyway to confirm the assignment to the new base channel you have selected. After the screen refreshes, check the checkbox to select the Production Example custom child channel. Click the Change Subscriptions button to confirm your selection. [root@desktopY ~]# yum -y remove example [root@desktopY ~]# yum install -y example ... Output Omitted ... Installing: example noarch 1.0-1 prod-example-custom ... Output Omitted
2.7 k
Practice Exercise
Update Notifications with RHN Errata Sign and import a newer (fixed) RPM into the Satellite Server. Create an errata to notify client system administrators that a fix has been published. Observe its impact on the client systems. 1.
Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the improved RPM, example-1.0-2.noarch.rpm, from /misc/instructor/RPMS to Charles' home directory and sign it with his GPG key. Import the new RPM into the Satellite Server so it is associated with the example-custom software channel. [channelman@desktopX ~]$ cp /misc/instructor/RPMS/example-1.0-2.* ~ [channelman@desktopX ~]$ rpm --resign example-1.0-2.noarch.rpm [channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom example-1.0-2.noarch.rpm
2.
Create and publish an errata notification that announces the availability of the example-1.0-2.noarch.rpm package. The errata synopsis should read, “example - file ownerships fixed”. Advisory EXBA2010:0001 release 1 is a bug fix advisory. Log into the Satellite Server as channelman since Channel Administrator privileges are needed to manage errata. Click on the Errata tab then select Manage Errata from the menu on the left. Click the create new erratum link in upper right-hand corner. Fill in the Errata Management form with the following values:
242
Field
Value
Synopsis
example - file ownerships fixed
Advisory
EXBA-2010:0001
RH401-6-en-1-20110713
Using Subversion to Manage Changes
Field
Value
Advisory Release
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
Appendix A. Solutions
[root@desktopY ~]# yum clean all [root@desktopY ~]# yum list updates ... Output Omitted ... Loaded plugins: rhnplugin Updated Packages example.noarch 1.0-2 example-custom
244
RH401-6-en-1-20110713
Building RPMs
Building RPMs Practice Quiz
RPM Spec File 1.
The package Version is usually derived from the open source project while the package Release is the packager's version.
2.
The name of the tarball containing the files used to build the package is specified with the Source directive.
3.
The BuildArch directive specifies the target architecture the package is being built for. noarch will be its value when the package can be installed on any architecture.
4.
The Summary directive specifies the one-line description of a package while the %description section provides a more thorough explanation of what that package is for.
5.
The %install section contains the code used to place files in the $RPM_BUILD_ROOT chroot directory structure.
6.
The %files section defines which files and directories to package into the RPM.
7.
The %prep , %build , %install and %clean sections contain shell code used to assemble a package and clean up after it has been built.
Test
Criterion Test Performance Checklist
Building an RPM Package Before you begin... If you haven't already done so, create a non-root user called student on your RHEL 6 workstation, desktopY. You will use this unprivileged account to build your RPM packages for RHEL 6 systems. In this exercise you will create an RPM for a package called “hello”. It should have version 1.0 with a release of 1 and it should be able to be installed on multiple architectures. Log in as root on desktopY and create a student account with a password of student. [root@desktopY ~]# useradd student [root@desktopY ~]# echo student | passwd --stdin student
Login as student on desktopY and make a directory called hello-1.0. Download the file ftp://instructor.example.com/pub/materials/hello.sh and save it in that directory.
RH401-6-en-1-20110713
245
Appendix A. Solutions
[student@desktopY ~]$ mkdir ~/hello-1.0 [student@desktopY ~]$ cd ~/hello-1.0 [student@desktopY hello-1.0]$ wget ftp://instructor.example.com/pub/materials/ hello.sh
Create a simple RPM that installs hello.sh in /usr/local/bin. Make sure hello.sh is installed with a mode of 755 and is owned by root on machines it is installed on. Also make sure the RPM can be installed on all architectures. First, create the necessary directory structure that rpmbuild requires. Also create the tar archive with the source files: [student@desktopY [student@desktopY [student@desktopY [student@desktopY
hello-1.0]$ cd ~]$ mkdir -p ~/rpmbuild/SOURCES ~]$ mkdir -p ~/rpmbuild/SPECS ~]$ tar -czvf ~/rpmbuild/SOURCES/hello-1.0-1.tar.gz hello-1.0
Next create a spec file for the package. Remember that vim on RHEL 6 will provide a template if you specify a file with a .spec extension: [student@desktopY ~]$ vim ~/rpmbuild/SPECS/hello.spec
The contents of ~/rpmbuild/SPECS/hello.spec should look like the following when you finish with your changes: Name: Version: Release: Summary: Group: License: URL: Source0: BuildRoot: BuildArch:
hello 1.0 1 Hello program RH401 GPL http://www.redhat.com %{name}-%{version}-%{release}.tar.gz /var/tmp/%{name}-buildroot noarch
%description hello.sh is a very friendly greeting program. on every system around the world.
It should be installed
%prep %setup -q -n %{name}-%{version} %build %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/local/bin install -m 755 hello.sh $RPM_BUILD_ROOT/usr/local/bin/hello.sh %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) /usr/local/bin/hello.sh
246
RH401-6-en-1-20110713
Building RPMs
%changelog * Thu Jun 9 2011 George - 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
Appendix A. Solutions
Configuration File Management with RHN Practice Performance Checklist
Creating and Populating a Configuration Channel Use your RHN Satellite Server to deploy configuration files. In this exercise you will create a Configuration Administrator account, create a configuration channel, and populate it with a custom configuration file for Example Inc. Create a Configuration Administrator account for the Example Inc. organization on your RHN Satellite Server. The account is for Ms. Janice Configurator and should have the login of configurator with a password of redhat. RHN Satellite generated e-mail for her should go to
[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.
Practice Performance Checklist
Deploying Configuration Files to a RHN Client Configure your client server so it will pull custom configuration file content from the configuration channel you created on your RHN Satellite Server. Entitle your client server, desktopY, to be able to install the tools necessary to provision it from your Satellite Server. Log in as configurator since she can manage systems in the example servers system group. Click the Systems tab then select the desktopY.example.com system link. Click on the Details tab followed by the Properties sub-tab. Within the Add-On Entitlements section select the Provisioning checkbox then click the Update Properties button. Install all necessary RHN configuration client software on desktopY. Configure your client system so it will permit configuration files to be deployed on it. First, subscribe your client system to the rhn-tools child software channel. Click the Systems tab then select the desktopY.example.com system link. Click on the Software tab followed by the Software Channels sub-tab. Select the checkbox by the relevant RHN Tools child channel then click the Change Subscriptions button to confirm your change.
RH401-6-en-1-20110713
249
Appendix A. Solutions
Because you added a new software channel, clean the yum cache on the client and install the rhncfg-actions RPM on desktopY: [root@desktopY ~]# ... Output Omitted [root@desktopY ~]# ... Output Omitted [root@desktopY ~]#
yum clean all ... yum install -y rhncfg-actions ... rhn-actions-control --enable-deploy
Modify the desktopY.example.com system profile so it subscribes to the exampleconfigs configuration channel. Execute commands on the client system so it downloads the configuration files provided by example-configs. Verify the new /etc/issue file successfully deploys. Click the Systems tab then select the desktopY.example.com system link. Choose the Configuration tab within the system overview page. Select the Manage Configuration Channels sub-tab then choose the Subscribe to Channels tab that appears. Check the Example Configs checkbox then click the Continue button. A page will appear entitled Step 2: Rank Channels for Subscription. Since we only have a single configuration channel, click the Update Channel Rankings button to complete the subscription. Execute the following command as root on desktopY: [root@desktopY ~]# rhncfg-client get Deploying /etc/issue
Verify the new /etc/issue file was successfully deployed by displaying its contents. [root@desktopY ~]# cat /etc/issue
Practice Performance Checklist
Command-line Configuration File Management Red Hat provides tools that allow and administrator to manage configuration channel content from the command-line. Use commands from the shell to update the configuration file content in your RHN Satellite Server. Install all necessary software on desktopY to perform configuration file management from the command-line. Create a directory called ~/config-mgmt where configuration files can be downloaded, modified, and uploaded back into the RHN Satellite Server. [root@desktopY ~]# yum install -y rhncfg-management ... Output omitted ... [root@desktopY ~]# mkdir ~/config-mgmt
Use the RHN command-line management tools to download the files for the exampleconfigs configuration channel below ~/config-mgmt. Modify the configuration channel's /etc/issue file so it contains the following content:
250
RH401-6-en-1-20110713
Building RPMs
*** Example Inc. *** No trespassing allowed. blank line
Use the command-line management tools to upload your change into your RHN Satellite Server. [root@desktopY ~]# rhncfg-manager download-channel -t config-mgmt/ example-configs Red Hat Network username: configurator Password: redhat Deploying /etc/issue -> config-mgmt/example-configs/etc/issue
When rhncfg-manager prompts for a RHN username and password, you must authenticate as either an Organization Administrator or a Configuration Administrator. [root@desktopY ~]# vi config-mgmt/example-configs/etc/issue [root@desktopY ~]# rhncfg-manager upload-channel -t config-mgmt/ -c example-configs Using config channel example-configs Uploading /etc/issue from config-mgmt/example-configs/etc/issue
Pull configuration files from the Satellite Server down to desktopY. Verify the most current version of /etc/issue has been deployed. [root@desktopY ~]# rhncfg-client get Deploying /etc/issue [root@desktopY ~]# cat /etc/issue *** Example Inc. *** No trespassing allowed.
RH401-6-en-1-20110713
251
Appendix A. Solutions
Provisioning with PXE Practice Exercise
Automating RHN Satellite Client Configuration Use an activation key to register newly installed machines to your Red Hat Network Satellite Server. It should subscribe the systems to useful software channels and join the Example Servers system group. 1.
Create an activation key with a label of example-web. When clients are registered with this activation key, the following actions should be performed: • Subscribe to the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base software channel • Subscribe to the related Red Hat Network Tools and Example custom child software channels • Provide a provisioning entitlement • Subscribe to the Example Configs configuration channel • Deploy configuration files provided by the Example Configs configuration channel • Associate with the Example Servers system group Log in as an Activation Key Administrator or an Organization Administrator for Example, Inc., in this case log in to the Satellite web interface as example. Navigate to the Create Activation Key screen. Select the Systems tab, choose Activation Keys from the menu at the left, then click the create new key link. When the Create Activation Key page appears, make the following selections: Field
Value
Description
Example Web Server
Key
orgID-example-web
Usage
leave this field blank
Base Channels
Select Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64)
Add-On Entitlements
Check the Provisioning checkbox
Universal Default
leave this checkbox unchecked
Click the Create Activation Key button to confirm your selections. Examine each of the tabs that are presented for the new activation key. Start with the Details tab. Check the Configuration File Deployment check box then click the Update Activation Key button to confirm your change.
252
RH401-6-en-1-20110713
Building RPMs
Select the Child Channels tab. Highlight both the Example custom and the RHN Tools for RHEL (v. 6 for 64-bit x86_64) child software channels. Click the Update Key button to register your changes. Select the Packages tab. Note the packages that are listed by default. Do not make any changes to this list. Click the Configuration tab then select the Subscribe to Channels sub-tab. Check the Example Configs checkbox. Click the Continue button to confirm your selection. Click the Groups tab then select the Join sub-tab. Check the Example Servers checkbox. Click the Join Selected Groups button to confirm your changes. 2.
Since signed packages will probably be deployed when the new systems are provisioned, the GPG keys used to verify their signatures need to be deployed as well. Import the GPG key used to verify custom packages built for Example, Inc. and the GPG key used to verify standard Red Hat released RPMS. These keys are found in /var/www/html/ pub/EXAMPLE-GPG-KEY and /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release respectively. You should still be logged in your Satellite Server as example, the Organization Administrator for Example, Incorporated. Navigate to the GPG Public Keys and SSL Certificates screen. Select the Systems tab, choose Kickstart from the menu at the left, then click the GPG and SSL Keys option from the sub-menu that appears. When the GPG Public Keys and SSL Certificates screen appears you should see the RHN-ORG-TRUSTEDSSL-CERT SSL key selected by default. Click the create new stored key/cert link and when the Create GPG/SSL Key page appears, make the following selections: Field
Value
Description
Example Custom Key
Type
Select GPG
Select file to upload
Click the Browse, then navigate to /var/ www/html/pub/EXAMPLE-GPG-KEY
Click the Create Key button to confirm your selections. When the GPG Public Keys and SSL Certificates screen appears you should see your key added. Perform the same steps listed above to import the GPG key Red Hat uses to check their package signatures. The Description should be Red Hat Release Key and the path to browse for that key is /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release.
Practice Exercise
Creating a Web Server Kickstart Profile Create a kickstart profile to build a web server that is ready to use immediately after it is installed from bare metal.
RH401-6-en-1-20110713
253
Appendix A. Solutions
1.
Create a kickstart profile labeled web-server that uses Red Hat Enterprise Linux 6 Server to install a new machine. This profile will be used for bare-metal installations without any use of virtualization. The most recent kickstart tree available should be used to perform the installation. The initial root password for systems built with this profile should be redhat. Click the Systems tab then choose Kickstart from the menu that appears. Click the create new kickstart profile link to advance to the Step 1: Create Kickstart Profile page. When it appears, make the following selections: Field
Value
Label
web-server
Base Channel
Select Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64)
Kickstartable Tree
Select ks-rhel-x86_64-server-6-6.0
Virtualization Type
Select None
Click the Next button. The Step 2: Distribution File Location screen should appear. Leave the Default Download Location radio button selected and click the Next button again. The final screen entitled Step 3: Root Password should appear. Specify a password of redhat, verify it, then click the Finish when done. 2.
The kickstart profile should create three native disk partitions. The first partition should contain a 256MB ext3 file system mounted as /boot. A swap partition should be created 2048MB large. The final native disk partition should be a 17GB LVM physical volume. Create a volume group named vol0 that includes the 17GB physical volume. Two logical volumes should be created within the vol0 volume group. The first logical volume should be named home and it should be 512MB in size. It will contain the /home filesystem. The second logical volume should be named root and it should consume the rest of the unused storage in vol0. It will be used for the / filesystem. Choose the appropriate time zone for your locale. Systems in this organization have hardware clocks which keep time using UTC instead of local time. The kickstart should install the GPG keys used to verify package signatures for RPMS released from Red Hat and custom packages provided by Example, Inc. To specify disk partitioning, within the kickstart profile click on the System Details tab. Select the Partitioning sub-tab and make the following adjustments: partition swap --size=2048 partition pv.01 --size=17000 partition /boot --fstype=ext3 --size=256 volgroup vol0 pv.01 logvol /home --vgname=vol0 --name=home --size=512 logvol / --vgname=vol0 --name=root --size=1000 --grow
Click the Update Partitions button to confirm your changes.
254
RH401-6-en-1-20110713
Building RPMs
To adjust the timezone, select the Locale sub-tab. Choose the appropriate timezone from the pull-down menu and check the Hardware Clock uses UTC check box. Click the Update Locale Preferences button to accept your selections. To install GPG keys used to sign RPMS, click on the System Details tab, then select the GPG & SSL sub-tab. The RHN-ORG-TRUSTED-SSL-CERT key should already be checked. Check the checkboxes by the Example Custom Key and the Red Hat Release Key selections. Click the Update keys button to confirm your selections. 3.
Systems built with this kickstart profile are web servers, but they are also used with graphical utilities and Subversion. Ensure the subversion RPM and the following package groups are installed: x11, basic-desktop, and web-server. For package selection, click the Software tab. The Package Groups sub-tab should be selected. Enter the following text into the dialog box on the display, one line per package group/package: @ Base @ x11 @ basic-desktop @ web-server subversion
Click the Update Packages button to confirm your changes. 4.
Update the kickstart profile so systems built with this profile register with the Red Hat Network Satellite Server using the Example Web Server activation key. Select the Activation Keys sub-tab (not the menu selection to left). Check the Example Web Server checkbox, then click the Update Activation Keys button to confirm your choice.
5.
Create a post script in the kickstart profile that performs the following tasks: • Create a user named oliver with a password of password • Install the example RPM provided by the custom software channel • Update all system software to its most current release • Configure the web server to start at boot Select the Scripts tab then click the add new kickstart script link. Complete the form that appears as follows: Field
Value
Scripting Language
Leave this field blank to use bash
Toggle Editor
Check/uncheck - your preference
Script Contents
*** see below ***
Script Execution Time
Select Post Script
nochroot
Leave unchecked
RH401-6-en-1-20110713
255
Appendix A. Solutions
Field
Value
Template
Leave unchecked
# Create our Subversion user useradd oliver echo password | passwd --stdin oliver # Install custom Example, Inc. RPM yum install -y example # Bring standard system software up to date yum update -y # Configure the web server to start at boot chkconfig httpd on
Click the Update Kickstart button to confirm your changes.
Practice Exercise
Set up the Provisioning Network Before desktopX provides any network services, it must be configured to communicate with and act as a gateway for its backend network. Also configure the Cobbler component of Red Hat Network Satellite Server to provide tftp and pxelinux capabilities for provisioning. Make sure Cobbler is installed and functioning properly. 1.
Physically disconnect your client workstation, desktopY, from the classroom network. Cable desktopY so it is connected to the second NIC of desktopX. This can be accomplished with either cross-over cables or with a small switch with two patch cables. Your instructor should have provided you with all necessary hardware to accomplish this task.
2.
Configure the backend interface of desktopX to have a static IP address of 10.100.X.254/24. You will not be able to fully test the backend interface until you power up and configure desktopY. Do a preliminary test by pinging the interface address. Edit /etc/sysconfig/network-scripts/ifcfg-eth1 to configure 10.100.X.254 as a static IP on the backend interface: DEVICE=eth1 ONBOOT=yes BOOTPROTO=static IPADDR=10.100.X.254 NETMASK=255.255.255.0
If your file includes a HWADDR line leave it in the interface configuration file. Do a preliminary test by pinging the interface address. [root@desktopX ~]# ifup eth1 [root@desktopX ~]# ping -c1 -s0 -W1 10.100.X.254
3.
Enable IPv4 packet forwarding on desktopX. Make sure this feature is persistent across reboots. Edit /etc/sysctl.conf to enable IPv4 packet forwarding at boot time:
256
RH401-6-en-1-20110713
Building RPMs
net.ipv4.ip_forward = 1
Load the settings in /etc/sysctl.conf into the kernel: [root@desktopX ~]# sysctl -p
4.
The following diagram represents the configuration of your lab environment when you finish this sequence:
RH401 Student Network Configuration =================================== -----+-------------------- Classroom intranet | eth0 | 192.168.0.X ,---+---. | | desktopX.example.com (desktopX) | | `---+---' | eth1 | 10.100.X.254 | | eth0 | 10.100.X.1 ,---+---. | | station1.privateX.com (desktopY) | | `-------'
5.
When installing Red Hat Network Satellite Server, the installer asks if Cobbler should be used to provide provisioning services. If it isn't already installed, use the cobbler-setup command to install Cobbler and enable tftp services. [root@desktopX ~]# cobbler-setup Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services (y/n, default = 'y')?y
6.
Run cobbler sync as root to install the necessary files to support PXE network bootloading. [root@desktopX ~]# cobbler sync
7.
Confirm xinetd and tftp are configured to run at boot time and that xinetd is currently running. [root@desktopX ~]# chkconfig xinetd --list [root@desktopX ~]# chkconfig tftp --list [root@desktopX ~]# service xinetd status
RH401-6-en-1-20110713
257
Appendix A. Solutions
Use chkconfig service on to configure tftp or xinetd to start at boot time if necessary. service xinetd start will launch xinetd if it is not already running.
Practice Exercise
Configure DHCP to Support PXE Install a DHCP server that will issue IP addresses, both generally and based on MAC address, to your provisioning network. 1.
Install the dhcp package on desktopX. [root@desktopX ~]# yum install -y dhcp
2.
Use the /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point for the DHCP server. • Change the subnet to 10.100.X.0/255.255.255.0. • Change the router to the IP address of the backend network interface of your DHCP server. • Set the DNS server to 192.168.0.254. • Set the default DNS search domain to example.com. • Issue IP addresses in the range from 10.100.X.2 to 10.100.X.10. • Deploy the network boot loader to support PXE booting. Configure your DHCP service to only issue IP addresses on the Ethernet card attached to the backend subnet. Copy /usr/share/doc/dhcp-*/dhcpd.conf.sample to /etc/dhcpd.conf. [root@desktopX ~]# cp /usr/share/doc/dhcp-*/dhcpd.conf.sample /etc/dhcpd.conf
Make changes to that file, so that the file looks something like the following. The X should match the last octet in the IP address of your frontend network interface. authoritative; ddns-update-style none; subnet 10.100.X.0 netmask 255.255.255.0 { option option option option
#
258
routers subnet-mask domain-name-servers domain-name
# change to your timezone option time-offset option time-offset
10.100.X.254; 255.255.255.0; 192.168.0.254; "example.com";
-18000; # EST -21600; # CST
RH401-6-en-1-20110713
Building RPMs
# #
option time-offset option time-offset
-25200; # MST -28800; # PST
range 10.100.X.2 10.100.X.10; default-lease-time 600; # 10 minutes max-lease-time 3600; # 1 hour next-server 10.100.X.254; filename "pxelinux.0"; }
Configure your DHCP service to only issue IP addresses on the Ethernet card attached to the backend subnet. For example if your backend interface is eth1, edit /etc/sysconfig/ dhcpd to include this line: DHCPDARGS=eth1
3.
In another terminal window or virtual console follow /var/log/messages. In your original shell start dhcpd and configure it to start at boot-time. PXE boot your client workstation. You may need to press a function key during the boot sequence to choose network boot. Observe /var/log/messages as well as the boot messages on desktopY. Record desktopY's MAC address for future reference: [root@desktopX ~]# tail -f /var/log/messages [root@desktopX ~]# service dhcpd start [root@desktopX ~]# chkconfig dhcpd on
desktopY should receive the IP address 10.100.X.10 since dhcpd offers addresses beginning with the last address in its range. /var/log/messages should contain a message like the following. Note the MAC address of desktopY. Jun
6 10:01:48 desktopX dhcpd: DHCPOFFER on 10.100.X.10 to 01:23:45:67:89:ab via eth1
It should have obtained the default Cobbler PXE configuration and therefore booted normally according to its BIOS settings. If desktopY has no other boot loader in the MBR or removable media, and PXE is configured in the list of boot options, this means your client may enter an endless PXE boot sequence! Power off desktopY. 4.
Use the MAC address of your second machine as recorded in /var/log/messages on desktopX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. The name of the client host will be station1.privateX.com. Restart the dhcpd service. PXE boot the client machine and verify that it gets the new address. It should also display the Cobbler PXE boot menu. Replace 12:34:56:78:AB:CD with the appropriate MAC address from /var/log/ messages. Replace X with your station number. For clarity, place the host declaration below the bottom of the subnet scope. subnet 10.100.X.0 netmask 255.255.255.0 { ...options truncated...
RH401-6-en-1-20110713
259
Appendix A. Solutions
} host station1 { hardware ethernet 12:34:56:78:AB:CD; fixed-address 10.100.X.1; }
[root@desktopX ~]# service dhcpd restart
Practice Exercise
PXE Installation of a Web Server Now that all the pieces are in place, kickstart a client system as a web server within the Example, Inc. organization. 1.
Delete all previous system profiles from the Satellite Server. This is required to free up all entitlements needed for the new web server that will be kickstarted. Log in to the Satellite Server web interface as example, the Organization Administrator for Example, Inc. Click the Systems tab then select the Systems menu item from the menu that appears. For each system displayed, click the host name link to bring up each system profile. Click the delete system link that appears at the top of the screen then click the Delete Profile button to confirm the deletion.
2.
Power on or reboot the client machine and select PXE boot. How PXE boot is selected varies between various hardware vendors. Notice the Cobbler menu that appears has a new menu item: web-server:orgID:ExampleInc
Use the arrow keys and choose this menu item to begin the installation of your web server. 3.
Once the installation completes, confirm the new web server is built according to specification. If anything didn't work properly, ask your instructor for help and troubleshoot your RHN Satellite configurations. [root@desktopY ~]# df -h ... Output Omitted ... [root@desktopY ~]# service httpd status ... Output Omitted ... [root@desktopY ~]# rpm -q gpg-pubkey gpg-pubkey-fd431d51-4ae0493b gpg-pubkey-2fa658e0-45700c69 gpg-pubkey-KEYID-4df66b78 [root@desktopY ~]# rpm -q subversion ... Output Omitted ... [root@desktopY ~]# date Should show your locale [root@desktopY ~]# yum list updates Should not display any packages [root@desktopY ~]# id oliver ... Output Omitted ...
260
RH401-6-en-1-20110713
Building RPMs
4.
Completely automate the PXE installation of your web server. Delete the existing system profile to free up entitlements before you being the automated installation. Configure the system BIOS to PXE boot first then boot from the local hard drive. Create a Cobbler system profile for your system called station1 based on the machine's IP address. Configure Cobbler to PXE boot only once by default and use the netbootenabled flag within the system profile to control installation. After you install your system and confirm everything worked correctly, delete the station1 Cobbler system profile so it doesn't conflict with later lab exercises. Log in to the Satellite Server web interface as example, the Organization Administrator for Example, Inc. Click the Systems tab then select the Systems menu item from the menu that appears. Click the host name link for your web server to bring up its system profile. Click the delete system link that appears at the top of the screen then click the Delete Profile button to confirm the deletion. Configure Cobbler to perform the automated installation via PXE: [root@desktopX ~]# cobbler list distros: ks-rhel-x86_64-server-6-6.0 profiles: web-server:orgID:ExampleInc systems: repos: images: [root@desktopX ~]# cobbler system add --name=station1 --profile=webserver:orgID:ExampleInc --ip=10.100.X.1 [root@desktopX ~]# cobbler system report --name=station1 | grep -i netboot Netboot Enabled? : True [root@desktopX ~]# grep pxe_just_once /etc/cobbler/settings pxe_just_once: 1 [root@desktopX ~]# rhn-satellite restart
Once the Satellite services have restarted, reboot the client system. The first time it PXE boots it will immediately begin a kickstart installation without displaying a menu. After it finishes installing, it should PXE boot again then boot from the local hard drive. After you confirm the installation worked properly, clean up the station1 system with cobbler to free up the IP address so it doesn't interfere with later labs. [root@desktopX ~]# cobbler system remove --name=station1
RH401-6-en-1-20110713
261
Appendix A. Solutions
RHN Virtual Machine Management Practice Exercise
Converting a Server to a Virtualization Host Before you begin... Your client machine, station1.privateX.com, will be transformed into a server that will host virtualization guest machines. Example, Inc. has existing machines registered with their Red Hat Network Satellite Server. Virtualization is being introduced to their server room so existing hosts need to be converted into virtualization hosts running virtual guests. 1.
First the network needs to be configured to provide a bridge network interface for virtual guests. Disable the NetworkManager service to prevent network configuration files from automatic modifications: [root@station1 ~]# chkconfig NetworkManager off [root@station1 ~]# service NetworkManager stop
Create/modify the network configuration files on station1 to support a network bridge. / etc/sysconfig/network-scripts/ifcfg-br0 should contain the following lines: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp DELAY=0 ONBOOT=yes
Modify /etc/sysconfig/network-scripts/ifcfg-eth0 so it contains the following lines: DEVICE=eth0 BRIDGE=br0 HWADDR=mac-address-of-eth0 ONBOOT=yes
Once the files have been modified, restart the network service and confirm station1 has a working network with br0 bridge. [root@station1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-br0 [root@station1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0 [root@station1 ~]# service network restart [root@station1 ~]# ip addr show br0 5: br0: 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
Appendix A. Solutions
[root@station1 ~]# yum install -y osad rhn-virtualization-host [root@station1 ~]# service osad start [root@station1 ~]# chkconfig osad on
3.
After the virtualization guest has finished installing, make sure the vserver domain is running. On the virtualization host run rhn_check and rhn-profile-sync as root. [root@station1 ~]# virsh start vserver [root@station1 ~]# rhn_check; rhn-profile-sync
4.
Log into the virtualization guest and download the bootstrap.sh script you completed in a previous lab from your Satellite Server. Use it to register the guest with your RHN Satellite Server. Using the graphical console in virt-manager, log in as root on vserver. Download the bootstrap.sh script you completed in a previous lab from your Satellite Server and use it to register the virtual machine to your RHN Satellite: [root@station? ~]# wget http://desktopX.example.com/pub/bootstrap/bootstrap.sh [root@station? ~]# chmod 755 bootstrap.sh [root@station? ~]# ./bootstrap.sh
5.
In the RHN web interface, select the Systems tab. You should see your newly-registered vserver virtual machine listed under its host name. Note the different system icon. Now click on your station1.privateX.com host name link, then on the system detail page find its Virtualization link/tab and click on that. You should see the list of the virtual machines running on station1 when you updated its RHN profile. If any of them are not registered with Red Hat Network, you will see “Unregistered System” instead of a host name for its profile name. Click on the hostname link for vserver (e.g. station9.privateX.com) to see its RHN profile.
Practice Exercise
Provisioning a Virtualization Host In previous exercises you converted an existing host to a virtualization host. Use RHN Satellite kickstart capabilities to provision a virtualization host from bare metal. 1.
Create a kickstart profile called kvm-host in your Satellite Server to build a virtualization host. The installing system should use the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the root password to redhat. Log into your RHN Satellite Server as a Kickstart Administrator or an Organization Administrator for Example, Inc. - the example user will work. Choose the Systems tab, select the Kickstart menu item then click the create new kickstart profile link. When the Step 1: Create Kickstart Profile form appears, complete it with the following values:
264
RH401-6-en-1-20110713
Building RPMs
Field
Value
Label
kvm-host
Base Channel
Select Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64)
Kickstartable Tree
Select ks-rhel-x86_64-server-6-6.0
Virtualization Type
Select None
Click the Next button to confirm your changes. When the Step 2: Distribution File Location screen appears, click the Next to accept the default kickstart tree location. Specify redhat as the default root password and click the Finish button to confirm your changes when the Step 3: Root Password screen appears. 2.
Once the kvm-host kickstart profile is created, adjust the timezone to use the local timezone and installed systems use UTC in their hardware clocks. Automate installation of the standard Red Hat release GPG key. The @virtualization, @virtualizationclient, and @virtualization-platform package groups should be installed. Use the %post script of the kickstart file to install the rhn-virtualization-host and osad packages. Configure the osad service to start at boot time. Also provide some shell code to configure the network to use a bridged network interface. Once the kvm-host kickstart profile is created, adjust the timezone to use the local timezone and installed systems use UTC in their hardware clocks. With the System Details tab selected within the kickstart profile, click the Locale tab and select the local timezone from the pull-down menu. Click the checkbox for UTC hardware clock then click the Update Locale Preferences to confirm your choices. Automate installation of the standard Red Hat release GPG key. With the System Details tab still selected, choose the GPG & SSL sub-tab, check the Red Hat Release Key checkbox, then click the Update keys button to confirm. Select the Software tab then select the Package Groups sub-tab. In the frame that appears, type @ virtualization, @ virtualization-client, and @ virtualizationplatform below the existing @ Base package group. Click on the Update Packages button when finished. To install the RHN virtualization management packages and create a bridged network interface, select the Scripts tab and create a %post script (not nochroot) with the following code: # Install virtualization management software yum install -y rhn-virtualization-host osad chkconfig osad on # Configure a network bridge chkconfig NetworkManager off cat > /etc/sysconfig/network-scripts/ifcfg-br0 > /etc/sysconfig/network-scripts/ifcfg-eth0
Click on the Update Kickstart button to accept your changes. 3.
Use the Satellite Server to schedule station1.privateX.com to kickstart install itself using the kvm-host kickstart profile. The kickstart should be initiated immediately. While the client system installs, use Cobbler to determine the system profile name of the kickstarting system. Delete all other Cobbler system profiles then disable the netboot feature for the installing system. Use the Satellite Server to schedule station1.privateX.com to kickstart install itself using the kvm-host kickstart profile. Navigate to the existing host profile. Choose the Systems tab, select Systems from the menu at the left, then click the host name link for the existing virtual host. Select the Provisioning tab within the system profile. The Kickstart and Schedule tabs should be selected. In the Select Kickstart Profile section of the page click the radio button by the kvm-host profile. The kickstart should be initiated immediately when the client system checks in so leave the radio button selected for Begin kickstart at the next system check in. Click the Schedule Kickstart and Finish button to confirm your changes and schedule the kickstart. Run rhn_check on station1 to facilitate the process: [root@station1 ~]# rhn_check
Broadcast warnings that the system will reboot should begin immediately. You can either wait a few minutes for the system to reboot itself or you can hurry the process along manually: [root@station1 ~]# reboot
After five minutes of warnings the client system will reboot and start the kickstart installation. While the client system installs, use Cobbler to determine the system profile name of the kickstarting system. Log in as root on the Satellite Server and execute the following commands: [root@desktopX ~]# cobbler list distros: ks-rhel-x86_64-server-6-6.0 profiles: kvm-host:orgID:ExampleInc web-server:orgID:ExampleInc systems: station1.privateX.com:orgID repos: images:
266
RH401-6-en-1-20110713
Building RPMs
Practice Exercise
Provisioning a Virtualized Guest With the virtualization host built, now it is time to use Red Hat Network Satellite to provision the virtual guests running on the host. 1.
Create a kickstart profile called kvm-guest in your Satellite Server to build a virtual guest. The installing system should use the Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the initial root password to redhat. Log into your RHN Satellite Server as a Kickstart Administrator or an Organization Administrator for Example, Inc. - the example user will work. Choose the Systems tab, select the Kickstart menu item then click the create new kickstart profile link. When the Step 1: Create Kickstart Profile form appears, complete it with the following values: Field
Value
Label
kvm-guest
Base Channel
Select Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64)
Kickstartable Tree
Select ks-rhel-x86_64-server-6-6.0
Virtualization Type
Select KVM Virtualized Guest
Click the Next button to confirm your changes. When the Step 2: Distribution File Location screen appears, click the Next to accept the default kickstart tree location. Specify redhat as the default root password and click the Finish button to confirm your changes when the Step 3: Root Password screen appears. 2.
Modify the virtual machine network configuration to use the br0 bridge interface of the virtualization host and send console messages to ttyS0. Adjust the timezone to use the local timezone and installed systems use UTC in their hardware clocks. Once the kvm-guest kickstart profile is created, notice the various options for CPU, memory, disk and network configuration available under the Details tab within the Kickstart Details tab. Enter br0 for the value of the Virtual Bridge field. In the Kernel Options field provide the value console=ttyS0. Click the Update Kickstart button to accept your changes. With the System Details tab selected within the kickstart profile, click the Locale subtab and select the local timezone from the pull-down menu. Click the checkbox for UTC hardware clock then click the Update Locale Preferences to confirm your choices.
3.
Use the RHN Satellite to provision a virtual guest on station1.privateX.com. Schedule a guest system to install using the kvm-guest kickstart profile. The guest name should be named vserver and initiate the kickstart installation immediately. Navigate to the existing virtualization host profile, station1.privateX.com. Choose the Systems tab, select Systems from the menu at the left, then click the hostname link for the existing virtual host. Select the Virtualization tab within the system profile, then the Provisioning tab. Do not select the higher level Provisioning tab. Check the radio button by
RH401-6-en-1-20110713
267
Appendix A. Solutions
the kvm-guest kickstart profile and specify a guest name of vserver. The kickstart should be initiated immediately when the client system checks in so leave the radio button selected for Begin kickstart at the next system check in. Click the Schedule Kickstart and Finish button to confirm your changes and schedule the kickstart. Log in as root on the client system serving as the virtualization host server. The virsh list command should show vserver running as it installs. Use the virsh console vserver command to display vserver's console as it installs. 4.
After the installation of the virtual guest completes, use the Satellite web interface to confirm that it has registered with the Satellite server. Navigate to the existing virtualization host profile, station1.privateX.com. Choose the Systems tab, select Systems from the menu at the left, then click the hostname link for the existing virtual host. Select the Virtualization tab within the system profile, then the Details tab. You should see an entry for the vserver virtualization guest in the list of hosts displayed.
268
RH401-6-en-1-20110713
RHN Satellite Server Administration
RHN Satellite Server Administration Practice Exercise
RHN Satellite Embedded Database Maintenance Perform basic RHN Satellite embedded database maintenance functions such as extending an internal table space and making a backup of your RHN Satellite database. 1.
Sometimes RHN Satellite embedded database performance can suffer when an internal table becomes full. Determine the current size and utilization of the UNDO_TBS table then extend it. Record both its original and new size and utilization below: First, log in as root on desktopX then switch to the oracle user so you can perform database administration. [root@desktopX ~]# su - oracle -bash-3.2$ db-control report Tablespace Size Used Avail DATA_TBS 3.9G 641.5M 3.2G SYSAUX 500M 110.8M 389.1M SYSTEM 400M 249.8M 150.1M UNDO_TBS 500M 146.3M 353.6M USERS 128M 64K 127.9M -bash-3.2$ db-control extend UNDO_TBS Extending UNDO_TBS... done. -bash-3.2$ db-control report Tablespace Size Used Avail DATA_TBS 3.9G 641.5M 3.2G SYSAUX 500M 110.8M 389.1M SYSTEM 400M 249.8M 150.1M UNDO_TBS 1000M 146.3M 853.6M USERS 128M 64K 127.9M
Use% 16% 22% 62% 29% 0%
Use% 16% 22% 62% 15% 0%
What is its new size and utilization? 2.
Perform a backup of your Red Hat Network embedded database. Save the backup in a directory called rhn-sat-backup-YYYYMMDD below the home directory of the oracle account. How much disk space does the backup take? Open another terminal window as root on desktopX so you can shutdown the Satellite Server so the database can be backed up: [root@desktopX ~]# rhn-satellite stop
In another window, get access to a shell as the oracle user. Create the directory where the backup will be stored then perform the backup: [root@desktopX ~]# su - oracle -bash-3.2$ mkdir rhn-sat-backup-YYYYMMDD -bash-3.2$ db-control backup rhn-sat-backup-YYYYMMDD Initiating cold backup of database rhnsat... /opt/apps/oracle/config/10.2.0/lkRHNSAT -> rhn-sat-backup-20100104/lkRHNSAT.gz ... done.
RH401-6-en-1-20110713
269
Appendix A. Solutions
/opt/apps/oracle/config/10.2.0/spfilerhnsat.ora -> rhn-sat-backup-20100104/ spfilerhnsat.ora.gz ... done. ... Output omitted ... Full cold backup complete.
Since the backup is finished, go to your other terminal window as root and restart the RHN Satellite Server software: [root@desktopX ~]# rhn-satellite start
How much disk space does the backup take? It should take up less than 1 GB of space. This is because it only backs up the essential database information - not the RPMS, the RHN Satellite software, nor the kickstart installation trees. -bash-3.2$ du -sh rhn-sat-backup-YYYYMMDD/ 699M rhn-sat-backup-YYYYMMDD/
3.
Confirm the integrity of the RHN Satellite embedded database backup you just created. Return to the window where you logged in as the oracle user and execute the following command: -bash-3.2$ db-control verify rhn-sat-backup-YYYYMMDD Verifying backup from Mon Jan 4 08:52:42 2010... rhn-sat-backup-20100104/lkRHNSAT.gz... done. Checksum verified. rhn-sat-backup-20100104/spfilerhnsat.ora.gz... done. Checksum verified. ... Output omitted ...
Practice Exercise
Activating a New Satellite Entitlement Certificate There are a couple of reasons a new RHN Satellite entitlement certificate is issued to a Red Hat customer: expanded capabilities or an extension on the certificate expiration date. In this exercise you will activate a new Satellite entitlement certificate that will provide more capabilities. •
On the instructor's server there is a more robust RHN Satellite entitlement certificate available for your use. You can access the certificate using the following pathname on your Satellite Server: /misc/instructor/rh401-satellite/redhat-glsmaximum-5.4.cert. Reactivate your Satellite Server using this certificate. Log in as your Satellite Administrator, satadmin, and inspect the system and software entitlements available for deployment. [root@desktopX ~]# cp /misc/instructor/rh401-satellite/redhat-gls-maximum-5.4.cert ~ [root@desktopX ~]# rhn-satellite-activate --disconnected --rhn-cert /root/redhat-glsmaximum-5.4.cert
270
RH401-6-en-1-20110713
RHN Satellite Server Administration
Log into your RHN Satellite server as the Satellite Administrator, satadmin. Click the Admin tab then select Subscriptions from the menu at the left. The total number of entitlements should be doubled and a number of free entitlements should be available for use.
Practice Exercise
Exporting Custom Child Software Channel Content Backing up the RHN Satellite embedded database does not preserve custom software channel content. Use rhn-satellite-exporter to backup your custom software channel content. 1.
Log in as root on desktopX and display the list of software channels currently in your RHN Satellite Server. Take note of the labels of the channels you want to save and the names of their parent channel. [root@desktopX ~]# rhn-satellite-exporter --list-channels Channel List: B = Base Channel C = Child Channel B rhel-x86_64-server-6 C example-custom C rhn-tools-rhel-x86_64-server-6 ... Output omitted ...
2.
Create a directory called custom-dump. Export the software channel content for the example-custom channel into custom-dump so it can be taken and imported into another disconnected Satellite Server. [root@desktopX ~]# mkdir custom-dump [root@desktopX ~]# rhn-satellite-exporter --step=short -d custom-dump -c rhel-x86_64server-6 10:18:36 Gathering channel info... 10:18:36 Gathering binary RPM info... 10:18:36 Gathering package info... 10:18:36 Gathering errata info... 10:18:36 Gathering kickstart data... 10:18:36 Gathering kickstart files info... ... Output omitted ... Exporting: #################### - Done! [root@desktopX ~]# rhn-satellite-exporter -d custom-dump -c example-custom 10:19:02 Gathering channel info... 10:19:02 Gathering binary RPM info... 10:19:02 Gathering package info... 10:19:02 Gathering errata info... 10:19:02 Gathering kickstart data... 10:19:02 Gathering kickstart files info... ... Output omitted ... Exporting: #################### - Done! [root@desktopX ~]# du -sh custom-dump 30M custom-dump
RH401-6-en-1-20110713
271
Appendix A. Solutions
3.
Confirm the channel content is usable with the satellite-sync command. Check carefully and be sure the example-custom channel appears in the output of satellitesync. [root@desktopX ~]# satellite-sync -m custom-dump -l 10:19:21 Red Hat Network Satellite - file-system synchronization 10:19:21 mp: /root/custom-dump 10:19:21 db: rhnsat/@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
Appendix A. Solutions
• Are the scripts executable? • Does SATELLITE_URL point to your Satellite Server? Were only the SATELLITE_* variable definitions modified? • Are SATELLITE_LOGIN and SATELLITE_PASSWORD defined to use Organization Administrator credentials for Example Inc.? Organization Administrator privileges are required to access user account information about an organization. API scripts run with privileges determined by the account they use to authenticate into the Satellite Server with. Optionally commit your changes to Subversion once your scripts are working and debugged.
[stan@desktopX api]$ svn commit -m 'Scripts working with Satellite server desktopX'
2.
Modify one of your working scripts to authenticate as the Satellite Administrator. How does this affect the behavior of the script? In one of the scripts change SATELLITE_LOGIN = 'example' to SATELLITE_LOGIN = 'satadmin' and run the script. For example: [stan@dsk; api]$ ./list-users.py satadmin
When you execute the script you should notice it doesn't list the users of Example Inc. because the Satellite Administrator is not a member of that organization.
Practice Exercise
Using the Red Hat API to Produce Reports Modify one of the provided scripts to produce a useful report by using the Red Hat Network API to get more detailed information about the users from your Satellite Server. •
Write a script, list-user-roles.pl or list-user-roles.py, that lists all of the users within the Example Inc. organization. Print the following information about each user: their login name and the list of their RHN administrative roles. Copy one of your working scripts as a starting point for your new script. Optionally maintain your script with revision control software. The following commands copy the working Python script and commits the original version into Subversion: [stan@desktopX api]$ svn copy list-users.py list-user-roles.py A list-user-roles.py [stan@desktopX api]$ svn commit -m 'Working on new script' ... Output omitted ...
274
RH401-6-en-1-20110713
RHN Application Programming Interface
The basic structure of the new program is the same as the sample scripts: connect to RHN, authenticate, list the users, then log out. Some additional work needs to be done when listing each user. The User namespace provides a method called listRoles that will get the information we need. This method takes a session key and a login name and returns an array of strings which are the RHN administrative roles assigned to the user. Additional Python code needed (the plus signs are not literal, they indicate which lines to add to the existing code): for user in ulist: login=user.get('login') print login + # Identify and print each user's roles: + rlist = client.user.list_roles(key, login) + for role in rlist: + print ' ' + role
Additional Perl code needed (the plus signs indicate which lines to add to the existing code): my $ulist = $client->call('user.list_users', $key); foreach my $user (@$ulist) { print $user->{'login'} . "\n"; + # Identify and print each user's roles: + my $rlist = $client->call('user.list_roles', $key, $user->{'login'}); + foreach my $role (@$rlist) { + print ' ' . $role . "\n"; + } }
The following shows what the output should look like when the script is working properly: [stan@desktopX api]$ ./list-user-roles.py example activation_key_admin config_admin monitoring_admin channel_admin org_admin system_group_admin normal grouper system_group_admin channelman channel_admin
Optionally check your changes in once your script is working: [stan@desktopX api]$ svn commit -m 'Working script'
RH401-6-en-1-20110713
275
Appendix A. Solutions
Test
Criterion Test Exercise
Using the RHN API to Perform Satellite Administration Write a couple Red Hat Network API scripts that perform RHN Satellite administration functions. 1.
Write two scripts that use the Red Hat Network API to administrate users. The userdisable.pl, or user-disable.py, script should deactivate a RHN user account. Its positive counterpart, user-enable.pl or user-enable.py, should reactivate an existing user account. Use a program variable for the RHN login to be enabled/disabled. These programs don't have to be fancy, they just have to be functional. There is no need to process command-line arguments or do extensive error checking. Optionally use revision control software to manage the changes you make to your new script. The basic structure of the new program is the same as the other RHN API scripts: connect to RHN, authenticate, enable/disable the specified user account, then log out. The User namespace provides a couple useful methods called enable and disable that will do what we need. These methods take a session key and the RHN login name of the account to manipulate. Below is working Perl code that implements the disable script: #!/usr/bin/perl -w use strict; use Frontier::Client; # Define RHN Satellite host and authentication values: my $SATELLITE_URL = 'https://desktopX.example.com/rpc/api'; my $SATELLITE_LOGIN = 'example'; my $SATELLITE_PASSWORD = 'redhat'; # Login name of user to disable: my $login_name = 'login_to_disable'; # Connect to the RHN Satellite Server: my $client = new Frontier::Client(url => $SATELLITE_URL); # Authenticate as a valid user to get a session key: my $key = $client->call('auth.login', $SATELLITE_LOGIN, $SATELLITE_PASSWORD); # Disable the user in our organization: $client->call('user.disable', $key, $login_name); # Logout from RHN session: $client->call('auth.logout', $key);
The Python solution is similar to the above code with a few syntactical differences. Also the enable function is a trivial change to the above program.
276
RH401-6-en-1-20110713
RHN Application Programming Interface
2.
Use one of your scripts to disable the channelman account. Go into the RHN Satellite web interface and verify his account has been disabled. Execute the other script to reactivate his account and verify that channelman can log into your Satellite Server. Optionally commit your changes to Subversion once your scripts are working and debugged. [stan@desktopX api]$ svn add user-disable.py user-enable.py OR [stan@desktopX api]$ svn add user-disable.pl user-enable.pl [stan@desktopX api]$ svn commit -m 'Added working administration API scripts'
RH401-6-en-1-20110713
277
Appendix A. Solutions
Comprehensive Review Practice Resequencing Exercise
Provisioning with a RHN Satellite Server Below are the steps you will take to deploy a provisioning Red Hat Network Satellite server. Take 5-10 minutes to prioritize and order the following steps. We will discuss them as a class before you begin to implement them. 4 12 16 7 1 6 3 13 2 9 15 11 17 10 14 8 5
Configure desktopX to serve as a Subversion repository. Clone the RHEL 6 Server base channel and all of its child channels. Create a kickstart profile. Import the relevant Red Hat software channels into the Satellite server. Install desktopX with Red Hat Network Satellite software. Prepare software channel content for import into the RHN Satellite. Deploy DHCP on desktopX and configure it to support PXE. Build and sign a custom RPM package on desktopY. Configure desktopX as a routing gateway for the backend network. Create a RHN system group. Create an activation key to automate system registration. Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Provision the client system using PXE menu. Create RHN user accounts, assign appropriate roles, and allow them to administrate a common system group. Import GPG keys into the Satellite server for deployment. Create a Red Hat Network organization and assign it system and software subscriptions. Import the open source project code into the Subversion repository.
Test
Criterion Test Case Study
Red Hat Network Satellite Server Deployment Requirements The following are the specifics for setting up your Red Hat Network Satellite server and client machine. desktopX should already be installed with a minimal RHEL 5 installation and desktopY will serve as your client server and should be installed with RHEL 6 server. The requirements for this review are specified in more detail below. They aren't necessarily listed in the order they are to be performed. • Install desktopX as a Red Hat Network Satellite software. The materials you need to perform the installation can be found in the /misc/instructor/rh401-satellite directory on desktopX. The installation ISO is named satellite-embedded-oracle-5.4.0-20101025rhel-5-x86_64.iso. Activate the Satellite server using the certificate named redhatgls-maximum-5.4.cert.
278
RH401-6-en-1-20110713
RHN Application Programming Interface
After the Satellite server is installed, create a satellite administrator account with a login of rhnsatadm and a password of redhat. • Prepare software channel content for import into the RHN Satellite. The content ISO's are in the rh401-satellite directory in a sub-directory called sat-rhel6-content. • Import the Red Hat software channels into the Satellite server that will support provisioning of RHEL 6 Servers. • Configure desktopX as a routing gateway for the backend network. The network addresses will be in the 10.100.X.0 subnet with a netmask of 255.255.255.0. The second network interface of desktopX should have a static address of 10.100.X.254. Ensure IPv4 packet forwarding is enabled persistently in the kernel. • Deploy DHCP on desktopX and configure it to support PXE provisioning. Determine the MAC address of desktopY and have DHCP consistently assign it the 10.100.X.7 IP address. Continue to use 192.168.0.254 for DNS services. • Build a custom RPM package on desktopY for the bubbles application. Consult the README and Makefile for information about building the package. Make sure both the binary executable and README are provided by the binary RPM that you create. The README should be classified as documentation by RPM. Generate a GPG key pair and sign the package. • Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Set the channel name to Custom Software with a label of custom-software. Specify the GPG key information you will use to verify the signature of RPMS you create. • Create a Red Hat Network organization called Review Inc.. The organization administrator should log in as review with a password of redhat. Assign all available entitlements to this organization. • Create a RHN system group in the Review Inc. organization called Review Systems. Put some meaningful text in the Description field. • Configure desktopX to serve as a Subversion repository. The top-level URL to access the directory should be svn+ssh://desktopX/var/local/svn. Create a group called svnusers and set permissions on the repository that allows all users in that group to create new projects and modify files. Create a user called builder on both systems. This user should be a member of the svnusers group on desktopX. Also create ssh keys on desktopY and deploy them so builder can check in files to the repository without providing a password. • Create RHN user accounts, assign appropriate roles, and allow them to administrate systems in the Review Systems system group according to the following table: Login
swadmin
cfgadmin
Password
redhat
redhat
Roles
Channel Administrator
Configuration Administrator
RH401-6-en-1-20110713
279
Appendix A. Solutions
• Import the open source project code for the "bubbles" program into the Subversion repository. The source code for this program can be found at the following URL: http://instructor/ pub/materials/bubbles-1.0.tar.gz. • Clone the RHEL 6 Server base channel and all of its child channels. Prefix the channel names with "Development" and the channel labels should have a "dev-" prefix. • Create an activation key to automate system registration. The key ID should be review-reg. It should register systems in the Review Inc. organization. Systems should join the Review Systems system group. They should also subscribe to cloned base software channel and rhntools and custom cloned channels. Also allow for configuration file provisioning and subscribe to the Review Configurations configuration channel. • Create a kickstart profile. It should register the provisioned system with the review-server activation key for Review Inc. It should install the web-server package group and update all available errata during its installation. The bubbles custom package should be installed and any available configuration files should be deployed. • Create a configuration channel called Review Configurations with a label of reviewconfigs. It provides /etc/issue which should contain the following text: Red Hat Enterprise Linux Server release 6.0 (Santiago) Kernel \r on an \m Review Inc.
• Import GPG keys into the Satellite server for deployment. Import the standard Red Hat key, RPM-GPG-KEY-redhat-release, and the GPG key used to verify custom packages. • Provision the client system using PXE menu provided by Cobbler. Confirm that it installed properly and is properly configured. •
280
RH401-6-en-1-20110713
