courses-commits November 2008

courses-commits@lists.fedorahosted.org

1 participants
1 discussions

en-US/Courses.xml Makefile Workshops/DeployingLinux Workshops/PuppetWorkshop

by Jeroen van Meeuwen

Makefile | 4 Workshops/DeployingLinux/Author_Group.xml | 24 Workshops/DeployingLinux/Book_Info.xml | 29 - Workshops/DeployingLinux/Common_Content/Feedback.xml | 45 - Workshops/DeployingLinux/Makefile | 3 Workshops/DeployingLinux/Preface.xml | 12 Workshops/DeployingLinux/en-US/Appendix.xml | 138 +++++ Workshops/DeployingLinux/en-US/Author_Group.xml | 30 - Workshops/DeployingLinux/en-US/Book_Info.xml | 48 - Workshops/DeployingLinux/en-US/Chapter.xml | 25 Workshops/DeployingLinux/en-US/Common_Content/Feedback.xml | 45 + Workshops/DeployingLinux/en-US/DeployingLinux.ent | 2 Workshops/DeployingLinux/en-US/DeployingLinux.xml | 12 Workshops/DeployingLinux/en-US/Deploying_Linux.ent | 4 Workshops/DeployingLinux/en-US/Deploying_Linux.xml | 334 +++++++++++++ Workshops/DeployingLinux/en-US/Preface.xml | 14 Workshops/PuppetWorkshop/Makefile | 5 Workshops/PuppetWorkshop/en-US/Preface.xml | 10 Workshops/PuppetWorkshop/en-US/Puppet_Workshop.ent | 5 Workshops/PuppetWorkshop/en-US/Puppet_Workshop.xml | 124 +++- en-US/Courses.xml | 2 21 files changed, 687 insertions(+), 228 deletions(-) New commits: commit a6dd29303bb5f0f6c322d45b57a01fc1ec16422e Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Wed Nov 12 01:27:55 2008 +0100 Updates diff --git a/Makefile b/Makefile index a395170..ef5751d 100644 --- a/Makefile +++ b/Makefile @@ -18,6 +18,10 @@ int-workshop: cp -a Workshops/PuppetWorkshop/en-US/* en-US/Books/Workshops/PuppetWorkshop/ cp -a en-US/Common_Content/Legal_Notice.xml en-US/Books/Workshops/PuppetWorkshop/Common_Content/Legal_Notice.xml cp -a en-US/Common_Content/Conventions.xml en-US/Books/Workshops/PuppetWorkshop/Common_Content/Conventions.xml + mkdir -p en-US/Books/Workshops/DeployingLinux/ + cp -a Workshops/DeployingLinux/en-US/* en-US/Books/Workshops/DeployingLinux/ + cp -a en-US/Common_Content/Legal_Notice.xml en-US/Books/Workshops/DeployingLinux/Common_Content/Legal_Notice.xml + cp -a en-US/Common_Content/Conventions.xml en-US/Books/Workshops/DeployingLinux/Common_Content/Conventions.xml html: clean int-workshop html-en-US diff --git a/Workshops/DeployingLinux/Author_Group.xml b/Workshops/DeployingLinux/Author_Group.xml deleted file mode 100644 index c9ba622..0000000 --- a/Workshops/DeployingLinux/Author_Group.xml +++ /dev/null @@ -1,24 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<authorgroup> - <author> - <firstname>Jeroen</firstname> - <surname>van Meeuwen</surname> - <affiliation> - <orgname>Operator Groep Delft</orgname> - <orgdiv>Sr. System Engineer</orgdiv> - </affiliation> - <email>j.van.meeuwen(a)ogd.nl</email> - </author> - <author> - <firstname>Stefan</firstname> - <surname>Hartsuiker</surname> - <affiliation> - <orgname>Operator Groep Delft</orgname> - <orgdiv>System Engineer</orgdiv> - </affiliation> - <email>s.hartsuiker(a)ogd.nl</email> - </author> -</authorgroup> diff --git a/Workshops/DeployingLinux/Book_Info.xml b/Workshops/DeployingLinux/Book_Info.xml deleted file mode 100644 index 2c5296f..0000000 --- a/Workshops/DeployingLinux/Book_Info.xml +++ /dev/null @@ -1,29 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<bookinfo id="PuppetWorkshop-Product_Name_and_Version"> - <title>Puppet Workshop</title> - <subtitle>Puppet Workshop</subtitle> - <issuenum>0.1</issuenum> - <productnumber>1</productnumber> - <edition>1</edition> - <pubsnumber>1</pubsnumber> - <abstract><para>This is a Configuration Management workshop (based on Puppet)</para></abstract> - <corpauthor> - <inlinemediaobject> - <imageobject> - <imagedata format='PNG' fileref="Common_Content/images/title_logo.png" /> - </imageobject> - </inlinemediaobject> - </corpauthor> - <copyright> - <year>&YEAR;</year> - <holder>&HOLDER;</holder> - </copyright> - <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -</bookinfo> - - - diff --git a/Workshops/DeployingLinux/Common_Content/Feedback.xml b/Workshops/DeployingLinux/Common_Content/Feedback.xml deleted file mode 100644 index 34b6b81..0000000 --- a/Workshops/DeployingLinux/Common_Content/Feedback.xml +++ /dev/null @@ -1,45 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<section> - <title>We Need Feedback!</title> - <indexterm> - <primary>feedback</primary> - <secondary>contact information for this manual</secondary> - </indexterm> - <para> - We would love to see your feedback! - </para> - <para> - Our mailing lists are as follows: - <itemizedlist> - <listitem> - <formalpara> - <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-users/" /></title> - <para> - Our "users" mailing list where anyone can comment on the course materials offered, provide other means of feedback and ask questions when things appear to not be as clear as they intend to be. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-devel/" /></title> - <para> - Our development mailing list for anyone seeking to get involved in the project. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-commits/" /></title> - <para> - This mailing list is used to send any changes made to any of the documents to anyone subscribed. - </para> - </formalpara> - </listitem> - </itemizedlist> - </para> -</section> - - diff --git a/Workshops/DeployingLinux/Makefile b/Workshops/DeployingLinux/Makefile index 4b0291f..f8d7e2e 100644 --- a/Workshops/DeployingLinux/Makefile +++ b/Workshops/DeployingLinux/Makefile @@ -3,7 +3,8 @@ XML_LANG = en-US DOCNAME = DeployingLinux PRODUCT = Fedora -BRAND = fedora +BRAND = ogd +#BRAND = fedora #OTHER_LANGS = as-IN bn-IN de-DE es-ES fr-FR gu-IN hi-IN it-IT ja-JP kn-IN ko-KR ml-IN mr-IN or-IN pa-IN pt-BR ru-RU si-LK ta-IN te-IN zh-CN zh-TW diff --git a/Workshops/DeployingLinux/Preface.xml b/Workshops/DeployingLinux/Preface.xml deleted file mode 100644 index d8e4a06..0000000 --- a/Workshops/DeployingLinux/Preface.xml +++ /dev/null @@ -1,12 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<preface id="PuppetWorkshop-Preface"> - <title>Preface</title> - <para> - paragraph - </para> - <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -</preface> diff --git a/Workshops/DeployingLinux/en-US/Appendix.xml b/Workshops/DeployingLinux/en-US/Appendix.xml new file mode 100644 index 0000000..ca88d80 --- /dev/null +++ b/Workshops/DeployingLinux/en-US/Appendix.xml @@ -0,0 +1,138 @@ +<?xml version='1.0'?> +<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<part id="DeployingLinux-Appendices"> + <title>Appendices</title> + <appendix id="DeployingLinux-Appendix-DhcpConfiguration"> + <title>DHCP Configuration</title> + <para> + Below is a sample DHCP configuration you can use: + </para> + <para> + <screen># +# DHCP Server Configuration file. +# see /usr/share/doc/dhcp*/dhcpd.conf.sample +# +# ****************************************************************** + +# +# generated from cobbler dhcp.conf template ($date) +# +# ****************************************************************** + +ddns-update-style interim; +update-static-leases on; + +ignore client-updates; +use-host-decl-names on; +authorative; + +local-address <replaceable>2.2.2.1</replaceable>; + +## +## Dynamic host magic +## +ddns-hostname = pick (option fqdn.hostname, option host-name, + concat ("dhcp-", + binary-to-ascii (10, 8, "-", leased-address)); +option host-name = config-option server.ddns-hostname; + +set vendorclass = option vendor-class-identifier; + +subnet <replaceable>2.2.2.0</replaceable> netmask <replaceable>255.255.255.0</replaceable> { + + authoritative; + + ddns-domainname "<replaceable>contoso.com</replaceable>"; + + option routers <replaceable>2.2.2.1</replaceable>; + option subnet-mask <replaceable>255.255.255.0</replaceable>; + option domain-name "<replaceable>contoso.com</replaceable>"; + option domain-name-servers <replaceable>2.2.2.1</replaceable>; + option netbios-name-servers <replaceable>2.2.2.1</replaceable>; + + pool { + range dynamic-bootp <replaceable>2.2.2.10</replaceable> <replaceable>2.2.2.250</replaceable>; + default-lease-time 86400; + max-lease-time 86400; + } + + allow bootp; + allow booting; + default-lease-time 21600; + max-lease-time 43200; + next-server <replaceable>2.2.2.1</replaceable>; + filename "/pxelinux.0"; +} + +zone <replaceable>contoso.com</replaceable>. { + primary 127.0.0.1; +} +zone <replaceable>2.2.2</replaceable>.in-addr.arpa. { + primary 127.0.0.1; +}</screen> + </para> + </appendix> + + <appendix id="DeployingLinux-Appendix-NamedConfiguration"> + <title>Named Configuration</title> + <para> + <screen>// +// Sample named.conf BIND DNS server 'named' +// configuration file +// +options +{ + // Put files that named is allowed to write in the data/ + // directory: + directory "/var/named"; // the default + dump-file "data/cache_dump.db"; + statistics-file "data/named_stats.txt"; + memstatistics-file "data/named_mem_stats.txt"; + + recursion yes; + +}; + +logging +{ +/* If you want to enable debugging, eg. using the 'rndc trace' + * command, named will try to write the 'named.run' file in + * the $directory (/var/named). By default, SELinux policy does + * not allow named to modify the /var/named directory, so put + * the default debug log file in data/: + */ + channel default_debug { + file "data/named.run"; + severity dynamic; + }; +}; + +include "/etc/named.root.hints"; + +zone "<replaceable>contoso.com</replaceable>" { + type master; + allow-update { 127.0.0.1; }; + file "dynamic/<replaceable>contoso.com</replaceable>.zone"; +}; + +zone "<replaceable>2.2.2</replaceable>.in-addr.arpa" { + type master; + allow-update { 127.0.0.1; }; + file "dynamic/<replaceable>2.2.2</replaceable>.in-addr.arpa.zone"; +}; + +include "/etc/rndc.key";</screen> + </para> + </appendix> + + <appendix id="DeployingLinux-Appendix-Kickstart"> + <title>Kickstart</title> + <para> + lala + </para> + </appendix> + + <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> +</part> diff --git a/Workshops/DeployingLinux/en-US/Author_Group.xml b/Workshops/DeployingLinux/en-US/Author_Group.xml index 474378e..88fd11f 100644 --- a/Workshops/DeployingLinux/en-US/Author_Group.xml +++ b/Workshops/DeployingLinux/en-US/Author_Group.xml @@ -3,14 +3,24 @@ ]> <authorgroup> - - <author> - <firstname>Dude</firstname> - <surname>McDude</surname> - <affiliation> - <orgname>My Org</orgname> - <orgdiv>Best Div in the place</orgdiv> - </affiliation> - <email>dude.mcdude(a)myorg.org</email> - </author> + <author> + <firstname>Jeroen</firstname> + <surname>van Meeuwen</surname> + <lineage>RHCE</lineage> + <affiliation> + <jobtitle>Sr. System Engineer</jobtitle> + <orgname>Operator Groep Delft</orgname> + </affiliation> + <email>j.van.meeuwen(a)ogd.nl</email> + </author> + <author> + <firstname>Stefan</firstname> + <surname>Hartsuiker</surname> + <lineage>RHCE</lineage> + <affiliation> + <jobtitle>System Engineer</jobtitle> + <orgname>Operator Groep Delft</orgname> + </affiliation> + <email>s.hartsuiker(a)ogd.nl</email> + </author> </authorgroup> diff --git a/Workshops/DeployingLinux/en-US/Book_Info.xml b/Workshops/DeployingLinux/en-US/Book_Info.xml index ca3249d..ec4aaf6 100644 --- a/Workshops/DeployingLinux/en-US/Book_Info.xml +++ b/Workshops/DeployingLinux/en-US/Book_Info.xml @@ -3,29 +3,31 @@ ]> <bookinfo id="DeployingLinux-Documentation"> - <title>DeployingLinux</title> - <subtitle>short descriptor</subtitle> - <productname>Documentation</productname> - <productnumber>1</productnumber> - <edition>1</edition> - <pubsnumber>0</pubsnumber> - <abstract> - <para>A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long. Note: the abstract will appear in the front matter of your book and will also be placed in the #description field of the book's RPM spec file.</para> - </abstract> - <corpauthor> - <inlinemediaobject> - <imageobject> - <imagedata format='SVG' fileref="Common_Content/images/title_logo.svg" /> - </imageobject> - <textobject><phrase>Logo</phrase></textobject> - </inlinemediaobject> - </corpauthor> - <copyright> - <year>&YEAR;</year> - <holder>&HOLDER;</holder> - </copyright> - <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <title>Deploying Linux</title> + <subtitle>Automatically Install, Upgrade and Deploy Linux</subtitle> + + <abstract> + <para>A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long. Note: the abstract will appear in the front matter of your book and will also be placed in the #description field of the book's RPM spec file.</para> + </abstract> + + <copyright> + <year>&YEAR;</year> + <holder>&HOLDER;</holder> + </copyright> + <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> </bookinfo> diff --git a/Workshops/DeployingLinux/en-US/Chapter.xml b/Workshops/DeployingLinux/en-US/Chapter.xml deleted file mode 100644 index 319438a..0000000 --- a/Workshops/DeployingLinux/en-US/Chapter.xml +++ /dev/null @@ -1,25 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="DeployingLinux-Test"> - <title>Test</title> - <para> - This is a test paragraph - </para> - <section id="DeployingLinux-Test-Section_1_Test"> - <title>Section 1 Test</title> - <para> - Test of a section - </para> - </section> - - <section id="DeployingLinux-Test-Section_2_Test"> - <title>Section 2 Test</title> - <para> - Test of a section - </para> - </section> - -</chapter> - diff --git a/Workshops/DeployingLinux/en-US/Common_Content/Feedback.xml b/Workshops/DeployingLinux/en-US/Common_Content/Feedback.xml new file mode 100644 index 0000000..70a9275 --- /dev/null +++ b/Workshops/DeployingLinux/en-US/Common_Content/Feedback.xml @@ -0,0 +1,45 @@ +<?xml version='1.0'?> +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<section> + <title>Feedback</title> + <indexterm> + <primary>Feedback</primary> + <secondary>Contact Information for this manual</secondary> + </indexterm> + <para> + Should you find any discrepancies or additional information for this documentation, we would appreciate to hear from you. + </para> + <para> + Our mailing lists are: + <itemizedlist> + <listitem> + <formalpara> + <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-users/" /></title> + <para> + Our "users" mailing list where anyone can comment on the course materials offered, provide other means of feedback and ask questions when things appear to not be as clear as they intend to be. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-devel/" /></title> + <para> + Our development mailing list for anyone seeking to get involved in the project. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><ulink url="http://lists.fedorahosted.org/mailman/listinfo/courses-commits/" /></title> + <para> + This mailing list is used to send any changes made to any of the documents to anyone subscribed. + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> +</section> + + diff --git a/Workshops/DeployingLinux/en-US/DeployingLinux.ent b/Workshops/DeployingLinux/en-US/DeployingLinux.ent deleted file mode 100644 index eb212ee..0000000 --- a/Workshops/DeployingLinux/en-US/DeployingLinux.ent +++ /dev/null @@ -1,2 +0,0 @@ -<!ENTITY PRODUCT "Documentation"> -<!ENTITY BOOKID "DeployingLinux"> diff --git a/Workshops/DeployingLinux/en-US/DeployingLinux.xml b/Workshops/DeployingLinux/en-US/DeployingLinux.xml deleted file mode 100644 index 045bbf9..0000000 --- a/Workshops/DeployingLinux/en-US/DeployingLinux.xml +++ /dev/null @@ -1,12 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<book> - <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Chapter.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <index /> -</book> - diff --git a/Workshops/DeployingLinux/en-US/Deploying_Linux.ent b/Workshops/DeployingLinux/en-US/Deploying_Linux.ent new file mode 100644 index 0000000..333e0ef --- /dev/null +++ b/Workshops/DeployingLinux/en-US/Deploying_Linux.ent @@ -0,0 +1,4 @@ +<!ENTITY PRODUCT "Documentation"> +<!ENTITY BOOKID "DeployingLinux"> +<!ENTITY HOLDER "Jeroen van Meeuwen"> +<!ENTITY YEAR "2008"> diff --git a/Workshops/DeployingLinux/en-US/Deploying_Linux.xml b/Workshops/DeployingLinux/en-US/Deploying_Linux.xml new file mode 100644 index 0000000..aa615a5 --- /dev/null +++ b/Workshops/DeployingLinux/en-US/Deploying_Linux.xml @@ -0,0 +1,334 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<book> + <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <chapter id="DeployingLinux-Introduction"> + <title>Introduction</title> + <para> + Cobbler is a Linux installation server that allows you to quickly set up a network installation environment. + </para> + <para> + Cobbler can provision systems using PXE, media-based net installations, virtualized installations (supporting Xen, QEMU, KVM and VMWare Server), according to various defined <emphasis>distributions</emphasis> and <emphasis>profiles</emphasis>. A <emphasis>distribution</emphasis> in this case is a Linux Distribution such as Red Hat Enterprise Linux or openSUSE, and a <emphasis>profile</emphasis> indicates what the target system should look like (webserver, fileserver, desktop, ...). Besides these aspects of provisioning systems, it can also help managing the infrastructure needed to deploy Linux, DHCP and DNS, as well as the TFTP directories for PXE environments. + </para> + <para> + With all that comes a nice web interface you can use for administration, including delegation of tasks. + </para> + <formalpara> + <title>Using PXE</title> + <para> + In this workshop, we will use PXE to provision systems. Using PXE has a feww prerequisites, but results in the most efficient and thus beneficial provisioning environment. A very minimal PXE environment would have at least one DHCP server and at least one TFTP server. With these two servers, any system can boot anything offered by the TFTP server (provided the offered materials are compatible with the system, of course). + </para> + </formalpara> + <para> + In order to be able to deploy Linux though, there's a few additional requirements to the PXE environment: + </para> + <para> + <orderedlist> + <listitem> + <para> + If a system is to boot an installation procedure, the installation procedure itself may need additional files to perform the installation. + </para> + </listitem> + <listitem> + <para> + For automated installations (true provisioning), if the installation procedure is supposed to get a couple of answers to questions it might have, it will need these answers one way or the other (<emphasis>kickstart</emphasis>, <emphasis>preseed</emphasis>, <emphasis>autoyast</emphasis>). + </para> + </listitem> + </orderedlist> + </para> + </chapter> + + <chapter id="DeployingLinux-HowThisWorks"> + <title>How This Works</title> + + <section id="DeployingLinux-HowThisWorks-UsingPXE"> + <title>Using PXE</title> + <para> + Preboot eXecution Environment (<emphasis>PXE</emphasis>, or <emphasis>pixie</emphasis>) is an environment to boot systems using a network interface independently from available storage devices or installed operating systems. + </para> + <note> + <para> + The term <emphasis>PXE Client</emphasis> only applies to the role the system takes in the PXE boot process. It can be a server, desktop, laptop or any other system. + </para> + </note> + <para> + A PXE client broadcasts a DHCPDISCOVER message extended with PXE specific options (<emphasis>extended DHCPDISCOVER</emphasis>) to port 67 over UDP (DHCP server port). When PXE is properly configured in the environment, the DHCP Server will respond with a broadcasted <emphasis>extended DHCPOFFER</emphasis> to port 68 over UDP (DHCP client port). This reply has to be broadcasted as the client does not yet have an IP address. + </para> + <para> + The extended DHCPOFFER sent by the DHCP server contains the IP address for the client as well as a few other options such as the TFTP server to use and the filename (or <emphasis>path</emphasis> to the file actually) to load, possibly verify and execute. This usually is a file called "<emphasis>/pxelinux.0</emphasis>". + </para> + <para> + A PXE Environment has the following components: + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title>DHCP Server</title> + <para> + A DHCP server configured to allow clients' BOOTP requests. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>TFTP Server</title> + <para> + A Trivial File Transfer Protocol server to enable the client to load the first stages and configuration for the PXE. + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + <para> + And in addition to this, when deploying Linux, you will need: + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title>File Server</title> + <para> + A server that serves the files needed for the installation. This typically includes the software packages to be installed, but also images used for the installation procedure. Most Linux distributions will allow you to either install from a NFS, FTP or HTTP source. + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + <para> + These three resources -the DHCP, TFTP and File server- will need to be kept in sync for the framework to work properly. The TFTP server will need the <filename>pxelinux.cfg</filename> files that correspond with the kickstart, preseed or autoyast configuration files and installation trees available on the file server. In addition, you will most likely have different <emphasis>profiles</emphasis> for each distribution to be installed on your systems, such as <emphasis>desktop</emphasis>, <emphasis>laptop</emphasis> and <emphasis>server</emphasis>. + </para> + <para> + In addition, you may not be at the console at the time you provision a server. Hence, you may be unable to have it boot from the network, select the correct menu entry, and/or review logs related to the installation procedure. + </para> + <para> + Cobbler takes care of most of these problems, and during this workshop, you will learn how. + </para> + </section> + + <section id="DeployingLinux-HowThisWorks-UsingInlineReplacement"> + <title>Using Inline Replacement</title> + <para> + Inline Replacement is where the running operating system decides to reboot into installation mode, using the appropriate <filename>vmlinuz</filename> and <filename>initrd.img</filename> for installing a system, booted with the parameters needed to start the (unattended) installation procedure. + </para> + <para> + A utility called <literal>koan</literal> is included with Cobbler, which lets you tell what Cobbler server to use (or discovers one on the network), what distribution or profile to install, and reboots the system into installation mode. This is ideal for bare metal provisioning; systems that do not support booting from the network, or systems that reside on a network that does not have the boot-from-network infrastructure. + </para> + </section> + + <section id="DeployingLinux-HowThisWorks-UsingCdrom"> + <title>Using a CD-ROM (set) or DVD (set)</title> + <para> + para + </para> + + <section id="DeployingLinux-HowThisWorks-UsingCdrom-CreatingACdrom"> + <title>Creating A CD-ROM (set) or DVD (set)</title> + <para> + You may use any of the composing utilities offered by the distribution in use to compose a CD-ROM (set) or DVD (set) of your own, and then use it to install the distribution with. + </para> + </section> + + </section> + + </chapter> + + + + <chapter id="DeployingLinux-InstallingAndConfiguringCobbler"> + <title>Installing and Configuring Cobbler</title> + <para> + This part of the workshop lets you install Cobbler, and configure cobbler, explaining some of the nifty features Cobbler has. + </para> + + <section id="DeployingLinux-InstallingAndConfiguringCobbler-Installation"> + <title>Installation</title> + <para> + To install Cobbler, use the following command: + </para> + <para> + <screen># <userinput>yum install cobbler</userinput></screen> + </para> + <para> + This will install the following packages: + </para> + <para> + <itemizedlist> + <listitem> + <para> + httpd + </para> + </listitem> + <listitem> + <para> + mod_python + </para> + </listitem> + <listitem> + <para> + python-devel + </para> + </listitem> + <listitem> + <para> + tftp-server + </para> + </listitem> + <listitem> + <para> + xinetd + </para> + </listitem> + <listitem> + <para> + createrepo + </para> + </listitem> + <listitem> + <para> + rsync + </para> + </listitem> + <listitem> + <para> + python-cheetah + </para> + </listitem> + </itemizedlist> + </para> + <para> + On any other distribution then Fedora, or Red Hat Enterprise Linux or CentOS with <ulink url="http://fedoraproject.org/wiki/EPEL">EPEL</ulink> configured and enabled, you will need to make sure these packages or their equivalents exist. + </para> + <para> + To finish Cobbler's installation, make sure the services related to a PXE infrastructure are installed as well: + </para> + <para> + <screen># <userinput>yum install dhcp named</userinput></screen> + </para> + <para> + The initial configuration for your dhcp and named server can be found in <xref linkend="DeployingLinux-Appendix-DhcpConfiguration" /> and <xref linkend="DeployingLinux-Appendix-NamedConfiguration" />. + </para> + <note> + <para> + The sample configuration files in the Appendices are for reference. Cobbler is going to manage the DHCP server and Named server. + </para> + </note> + + <section id="DeployingLinux-InstallingAndConfiguringCobbler-Installation-CheckingTheInstallation"> + <title>Checking The Installation</title> + <para> + There's a few commands you can use to check the installation you are running. This can be useful in later diagnostics as well; + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title><userinput>cobbler check</userinput></title> + <para> + Have cobbler check what else you may need to pay attention to. Very useful diagnostic tool. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><userinput>rpm -qV <replaceable>cobbler</replaceable></userinput></title> + <para> + Verify that all the files that the package installs are intact; compare them to the original state. In this case, the files installed by the package <replaceable>cobbler</replaceable> are verified. Useful in tracing the steps you have taken. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><userinput>rpm -qld <replaceable>cobbler</replaceable></userinput></title> + <para> + List all files marked as <emphasis>documentation</emphasis>, in this case for the <replaceable>cobbler</replaceable> package. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><userinput>rpm -qlc <replaceable>cobbler</replaceable></userinput></title> + <para> + List all files marked as <emphasis>configuration</emphasis>, in this case for the <replaceable>cobbler</replaceable> package. + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + </section> + + </section> + + <section id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration"> + <title>Configuring Cobbler</title> + <para> + This section + </para> + + <section id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDhcp"> + <title>Manage DHCP</title> + <para> + para + </para> + </section> + + <section id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDns"> + <title>Manage DNS</title> + <para> + para + </para> + </section> + + </section> + + </chapter> + + <chapter id="DeployingLinux-PerformingAutomatedInstallations"> + <title>Performing Automated Installations</title> + <para> + Provisioning rises or falls with the ability to perform automated installations of a distribution. Most commonly, methods to perform automated installations include answers to questions the installation procedure might have, package selection (which is actually a question from the installater's point of view). + </para> + + <section id="DeployingLinux-PerformingAutomatedInstallations-RedhatCentosAndFedora"> + <title>Fedora, Red Hat Enterprise Linux and CentOS</title> + <para> + Fedora, Red Hat Enterprise Linux, CentOS and derivative distributions use kickstart to answer the questions of the normal installation procedure, as well as provide additional customization support in the form of <literal>%pre</literal> and <literal>%post</literal> scripts. + </para> + </section> + + <section id="DeployingLinux-PerformingAutomatedInstallations-DebianAndUbuntu"> + <title>Debian and Ubuntu</title> + <para> + preseed + </para> + </section> + + <section id="DeployingLinux-PerformingAutomatedInstallations-SuseAndOpensuse"> + <title>SUSE and openSUSE</title> + <para> + autoyast + </para> + </section> + </chapter> + + <chapter id="DeployingLinux-ProvisionedSystemInitialConfiguration"> + <title>Initial Configuration of the Provisioned System</title> + <para> + para + </para> + </chapter> + + <xi:include href="Appendix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + +</book> + diff --git a/Workshops/DeployingLinux/en-US/Preface.xml b/Workshops/DeployingLinux/en-US/Preface.xml index 0ab7049..1e3980e 100644 --- a/Workshops/DeployingLinux/en-US/Preface.xml +++ b/Workshops/DeployingLinux/en-US/Preface.xml @@ -3,11 +3,11 @@ ]> <preface id="DeployingLinux-Preface"> - <title>Preface</title> - <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"> - <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"> - <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - </xi:fallback> - </xi:include> + <title>Preface</title> + <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"> + <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"> + <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + </xi:fallback> + </xi:include> </preface> diff --git a/Workshops/PuppetWorkshop/Makefile b/Workshops/PuppetWorkshop/Makefile index 22c7679..7e5e176 100644 --- a/Workshops/PuppetWorkshop/Makefile +++ b/Workshops/PuppetWorkshop/Makefile @@ -15,5 +15,6 @@ COMMON_CONFIG = /usr/share/publican include $(COMMON_CONFIG)/make/Makefile.common kanarip: pdf-en-US html-single-en-US - rsync -rlHvz --delete --progress --rsh=ssh tmp/en-US/html-single/ pinky:/data/www/kanarip.com/www/public_html/courses/puppet/ - rsync -rlHvz --delete --progress --rsh=ssh tmp/en-US/pdf/Puppet_Workshop.pdf pinky:/data/www/kanarip.com/www/public_html/courses/puppet/puppet.pdf + rsync -rlHvz --progress --rsh=ssh tmp/en-US/html-single/ pinky:/data/www/kanarip.com/www/public_html/courses/puppet/ + rsync -rlHvz --progress --rsh=ssh tmp/en-US/pdf/Puppet_Workshop.pdf pinky:/data/www/kanarip.com/www/public_html/courses/puppet/puppet.pdf + rsync -rlHvz --progress --rsh=ssh Puppet\ Workshop.odp pinky:/data/www/kanarip.com/www/public_html/courses/puppet/puppet.odp diff --git a/Workshops/PuppetWorkshop/en-US/Preface.xml b/Workshops/PuppetWorkshop/en-US/Preface.xml index 854b20d..dfba1f0 100644 --- a/Workshops/PuppetWorkshop/en-US/Preface.xml +++ b/Workshops/PuppetWorkshop/en-US/Preface.xml @@ -23,7 +23,7 @@ <formalpara> <title>Contributors</title> <para> - <emphasis>Stefan Hartsuiker</emphasis> (RHCE, LPIC-2, MCP) is currently a System Engineer, specialized in maintaining Linux Systems, also working for Operator Group Delft in the Netherlands and a colleague of Jeroen van Meeuwen. His experience with computers started in the late 80's with a Acorn Electron, a smaller version of the BBC Electron (no it had nothing to do with the British Broadcasting Company), for which he had to type in several pages worth of lines of code just to play a game. His first introduction to Linux came in the early 90's with the slackware distribution on about 32 floppies. Since then he has used and maintained Suse, Debian, RedHat and Fedora systems. + <emphasis>Stefan Hartsuiker</emphasis> (RHCE, LPIC-2, MCP) is currently a System Engineer, specialized in maintaining Linux Systems, also working for Operator Groep Delft in the Netherlands and a colleague of Jeroen van Meeuwen. His experience with computers started in the late 80's with a Acorn Electron, a smaller version of the BBC Electron (no it had nothing to do with the British Broadcasting Company), for which he had to type in several pages worth of lines of code just to play a game. His first introduction to Linux came in the early 90's with the slackware distribution on about 32 floppies. Since then he has used and maintained Suse, Debian, RedHat and Fedora systems. </para> </formalpara> <para> @@ -31,12 +31,12 @@ </para> </section> - + </section> <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> diff --git a/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.ent b/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.ent new file mode 100644 index 0000000..217c9e0 --- /dev/null +++ b/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.ent @@ -0,0 +1,5 @@ +<!ENTITY PRODUCT "Documentation"> +<!ENTITY BOOKID "PuppetWorkshop"> +<!ENTITY HOLDER "Jeroen van Meeuwen"> +<!ENTITY PROVIDER "Operator Groep Delft"> +<!ENTITY YEAR "2008"> diff --git a/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.xml b/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.xml index 34a3c03..0ef8ff8 100644 --- a/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.xml +++ b/Workshops/PuppetWorkshop/en-US/Puppet_Workshop.xml @@ -20,7 +20,7 @@ </listitem> <listitem> <para><emphasis>Introduction to Puppet</emphasis></para> - <para>An introduction to how puppet resolves many of the issues that exist without configuration management.</para> + <para>An introduction to how Puppet resolves many of the issues that exist without configuration management.</para> </listitem> <listitem> <para><emphasis>Puppet Terminology</emphasis></para> @@ -50,6 +50,7 @@ </listitem> <listitem> <para><emphasis>Best Practices</emphasis></para> + <para>More Tips & Tricks on Puppet</para> </listitem> </itemizedlist> </para> @@ -170,7 +171,7 @@ <formalpara> <title>Maintain consistency across systems</title> <para> - Consistency across systems is key in understanding where a problem might come from. If each and every system is unique, you may end up searching for unique aspects of the system's configuration in order to determine the cause of a problem, while if systems are mostly consistent and the exceptions to the rule are determined or determinable, you may have found the problem even before your users report it. + Consistency across systems is key in understanding where a problem might come from and assessing where problems may be first introduced. If each and every system is unique, you may end up searching for unique aspects of the system's configuration in order to determine the cause of a problem, while if systems are mostly consistent and the exceptions to the rule are easily determined, you may have found the problem even before your users experience the consequences. </para> </formalpara> <formalpara> @@ -184,13 +185,13 @@ <formalpara> <title>Categorize systems</title> <para> - Categorizing systems into categories like (for example) <emphasis>desktop</emphasis>, <emphasis>server</emphasis> and/or <emphasis>laptop</emphasis>, helps in applying changes to one category, such as installing <application>GNOME</application> or keeping systems up-to-date according to a schedule that may (servers) or may not (desktops, laptops) need a service or maintenance window. + Grouping systems into categories like (for example) <emphasis>desktop</emphasis>, <emphasis>server</emphasis> and/or <emphasis>laptop</emphasis>, helps in applying changes to one category, such as installing <application>GNOME</application> or keeping systems up-to-date according to a schedule that may (servers) or may not (desktops, laptops) need a service or maintenance window. </para> </formalpara> <formalpara> <title>Different profiles</title> <para> - More generally speaking, different profiles for each of these categories may be defined as well, of course. A developer's desktop most likely has different requirements then a publicly accessible booth at the reception desk. + More generally speaking, different profiles for each of these categories may be defined as well. A developer's desktop most likely has different requirements then a publicly accessible information booth at the reception desk. </para> </formalpara> </listitem> @@ -198,7 +199,7 @@ <formalpara> <title>Version Control</title> <para> - Version control lets you keep track of changes applied to the overall configuration management framework, which is important because since you are managing different aspects of a (large) number of systems, if something goes wrong the changes applied to the configuration of puppet will most likely be the first clue as to what caused the new problem and lets you recover relatively fast. Additionally, version control adds a layer that also gives you the chance to perform access control, to have notifications of changes applied sent to interested people, and to branch off. + Version control lets you keep track of changes applied to the overall configuration management framework, which is important because if you are managing different aspects of a (large) number of systems, and something goes wrong, the changes applied to the configuration Puppet uses will most likely be the first clue as to what caused the new problem and lets you recover relatively fast. Additionally, version control adds a layer that also gives you the chance to perform access control, to have notifications of changes applied sent to interested people, and to branch off. </para> </formalpara> </listitem> @@ -235,7 +236,7 @@ <formalpara> <title>Different operating systems</title> <para> - If you have a diverse organization in terms of the operating systems your systems run, applying the same configuration items to a set of different operating systems is challenging in that adding a user or setting a password on one operating system is not the same as adding a user or setting a password on another operating system. The same applies to installing, updating or removing a package, and so forth. Additionally the more different operating systems you have, the harder managing any given system resource becomes. Some commands for day-to-day administrative tasks may be equal, or similar, but most of them are and/or behave different. + If you have a diverse organization in terms of the operating systems your systems run, applying the same or similar configuration to a set of different operating systems is challenging in terms of adding a user or setting a password on one operating system is not the same as adding a user or setting a password on another operating system. The same applies to installing, updating or removing a package, and so forth. Additionally the more different operating systems you have, the harder managing any given <emphasis>system resource</emphasis> becomes. Some commands for day-to-day administrative tasks may be equal, or similar, but most of them are and/or behave different. </para> </formalpara> </listitem> @@ -251,7 +252,7 @@ <formalpara> <title>Different versions of distributions</title> <para> - Different versions of distributions, or more accurately the different versions of the utilities, as well as the configuration settings for updated programs that come with the distributions, can form a challenge when or if the organization does not have a proper configuration management framework in place. Note that even though an organization may not have different versions of a distribution right now, at some point the organization will need to upgrade to the next available release. + Different versions of distributions, or, more accurately, the different versions of the applications shipped with each distribution version, as well as the configuration settings for updated programs that come with the distributions, can form a challenge when or if the organization does not have a proper configuration management framework in place. Note that even though an organization may not have different versions of a distribution right now, at some point the organization will need to upgrade to the next available release. </para> </formalpara> </listitem> @@ -267,7 +268,7 @@ <formalpara> <title>Different ways to perform a task</title> <para> - Within an organization that has multiple servers performing the same task, keeping a similar state or perform a task in a similar manner is challenging in that without configuration management, you are most likely to find three or more ways to purge old files from <filename>/tmp/</filename> and <filename>/var/tmp/</filename>, for example. The same differentiation may apply to how webservers' VirtualHosts are configured, or how a NFS share is mounted (mount options in particular). + Within an organization that has multiple servers performing the same task, keeping a similar state or perform a task in a similar manner is challenging in the sense that without configuration management, you are most likely to find more and more ways to purging old files from <filename>/tmp/</filename> and <filename>/var/tmp/</filename>, for example. The same differentiation may apply to how webservers' VirtualHosts are configured, or how a NFS share is mounted (mount options in particular). </para> </formalpara> </listitem> @@ -275,7 +276,7 @@ <formalpara> <title>Different nodes</title> <para> - This one goes to hardware-specific needs and configuration. When each of the systems in an organization are not all of the same brand, make and model, or each system has different harddisk layouts, or needs different videocard drivers, you are basically keeping lists and making choices based on this list. + This one goes to hardware-specific needs and configuration. When the systems in an organization are not all of the same brand, make and model, or each system has different harddisk layouts, or needs different videocard drivers, you are basically keeping lists and making choices based on those lists. </para> </formalpara> </listitem> @@ -283,7 +284,7 @@ <formalpara> <title>Different services</title> <para> - Different services of course are configured differently, as far as configuration file locations and syntax are concerned. However, figuring out the best way to apply certain configuration to a system for each service is less efficient without configuration management. You might adjust a script or two and/or adjust the source repository from which you pull updates to each machine, but the changes may turn out to only apply to that system that needed the exception to the rule instead of focussing on a more general solution to the problem once, and apply that solution multiple times, over and over again. + Different services of course are configured differently, as far as configuration file locations and syntax are concerned. However, figuring out the best way to apply certain configuration to a system for each service is less efficient without configuration management. You might adjust a script or two and/or adjust the source repository from which you pull updates to each system, but the changes may turn out to only apply to that system that needed the exception to the rule instead of focussing on a more general solution to the problem once, and apply that solution multiple times, over and over again. Overview is key here, even if your standard environment exists of numerous different profiles. </para> </formalpara> </listitem> @@ -291,7 +292,7 @@ <formalpara> <title>Interfaces to a system resource</title> <para> - This is probably the hardest one if you are not using any configuration management framework. Given different operating systems, distributions and/or distribution versions, in which case any combination of the three only makes the problem harder to solve, you are most likely to encounter so many different ways to manage a given system resource, that a simple script or routine cannot cover all of them -and remain comprehensible and maintainable. One example is adding a user to the system, and making the user a group member of several groups. You may find routines ranging from using <application>useradd</application> or <application>adduser</application> depending on the distribution used, to writing out ldifs from a template and using <application>ldapadd</application> or <application>ldapmodify</application> depending on whether the user already exists or not. + This is probably the hardest one if you are not using any configuration management framework. Given different operating systems, distributions and/or distribution versions, in which case any combination of the three only makes the problem harder to solve, you are most likely to encounter so many different ways to manage a given system resource, that a simple script or routine cannot cover all of them -and remain comprehensible and maintainable. One example is adding a user to the system, and making the user a group member of several groups. You may find routines ranging from using <application>useradd</application> or <application>adduser</application> depending on the distribution used, to writing out ldifs from a template and using <application>ldapadd</application> or <application>ldapmodify</application> depending on whether the user already exists or not, and whether the user is a member of the group already. </para> </formalpara> </listitem> @@ -299,7 +300,7 @@ <formalpara> <title>Fast pace changes</title> <para> - Changes that need to apply rather sooner then later are often only applied by the time a crontab job polls for new configuration, or when a system reboots. This does not work in cases where changes need to be applied quickly, such as when a package installed on some or all systems exposes remotely exploitable vulnerabilities. + Changes that need to be applied sooner rather then later are often only applied by the time a crontab job polls for new configuration, or when a system reboots. This does not work in cases where changes need to be applied quickly, such as when a package installed on some or all systems exposes vulnerabilities that make the system remotely exploitable. </para> </formalpara> </listitem> @@ -326,7 +327,7 @@ <formalpara> <title>Keeping track of changes</title> <para> - Another challenge is keeping track of the changes applied to each system. Even with configuration management, errors can be made and systems might behave unexpectedly, in which case you will want to know what changed on these systems, and how to recover to an operational state. Keeping track of changes without a configuration management framework however is a little harder, but with configuration management, you have reports (changes applied to a system in a nice overview), and most advisebly you have the configuration for Puppet stored in a Source Control Management system, or SCM system, like CVS, SVN, Mercurial, or GIT. + Another challenge is keeping track of the changes applied to each system. Even with configuration management, errors can be made and systems may behave unexpectedly, in which case you will want to know what changed on these systems, and how to recover to an operational state. Keeping track of changes without a configuration management framework however is a little harder, but with configuration management, you have reports (changes applied to a system in a nice overview), and most advisebly you have the configuration for Puppet stored in a Source Control Management system, or SCM system, like CVS, SVN, Mercurial, or GIT. </para> </formalpara> </listitem> @@ -334,7 +335,7 @@ <formalpara> <title>Staging changes</title> <para> - Staging changes is a huge must-have in case changes are radical or might destroy a normal system's operation (even if temporary). For such changes, you would want to test the changes first, and with Puppet, you get this in the form of <emphasis>environments</emphasis>. Additionally, in case any critical component needs to change, proper Change Management then requires you to Build & Test the solution prior to implementation, often not a very bad idea to relieve stress in case the implemented solution does not work, especially if the change is time-constrained such as with service windows. + Staging changes is a huge must-have in case changes are radical or might destroy a normal system's operation (even if temporary). For such changes, you would want to test the changes first, and with Puppet, you get this in the form of <emphasis>environments</emphasis>. Additionally, in case any critical component needs to change, proper Change Management then requires you to Build & Test the solution prior to implementation. This is often not a very bad idea to relieve stress in case the implemented solution does not work, especially if the change is time-constrained such as with service windows. </para> </formalpara> </listitem> @@ -342,7 +343,7 @@ <formalpara> <title>Exceptions to the rule</title> <para> - As important as keeping systems consistent, is being able to name and point out the exceptions to the rules that you set. Of course, every organization has exceptions and until the point where high-availability, high-performance, load-balancing or virtualization clusters are deployed (or storage pools for that matter), no two systems are alike. Trying to keep a consistent configuration amongst all your systems doesn't change that. Note though, being able to reproduce the reasoning behind the exceptions to the rule is important in recovering from (unexpected) interruptions. + As important as keeping systems consistent is being able to name and point out the exceptions to the rules that you set. Of course, every organization has exceptions and until the point where high-availability, high-performance, load-balancing or virtualization clusters are deployed (or storage pools for that matter), no two systems are alike. Trying to keep a consistent configuration amongst all your systems doesn't change that. Note though, being able to reproduce the reasoning behind the exceptions to the rule is important in recovering from (unexpected) system or service interruptions. </para> </formalpara> </listitem> @@ -350,7 +351,7 @@ <formalpara> <title>Restoring a system</title> <para> - Restoring a system to it's normal operations often requires you to have a backup of the most recent configuration files and transactional data for the machine. Although configuration management with puppet does not facilitate the backup of transactional data, it does facilitate the backup of configuration files, taking away the rather boring task of having to select manually which items need to be backed up and restored on a regular basis. + Restoring a system to it's normal operations often requires you to have a backup of the most recent configuration files and transactional data for the machine. Although configuration management with puppet does not facilitate the backup of transactional data, it does facilitate the backup of configuration files, taking away the rather boring task of having to manually select which items need to be backed up on a regular basis, and restored when recovering the system. </para> </formalpara> </listitem> @@ -578,7 +579,7 @@ node '<replaceable>node3.example.com</replaceable>' { }</screen> </para> <para> - While instead, since these are all desktops, we could create a <filename>groups/desktop.pp</filename> that says: + While instead, since these are all using the same "profile", <emphasis>desktop</emphasis>, we could create a <filename>groups/desktop.pp</filename> that says: </para> <para> <screen>class desktop { @@ -641,7 +642,7 @@ node '<replaceable>node1.example.com</replaceable>' inherits desktop { <formalpara id="PuppetWorkshop-PuppetTerminology-class"> <title>class</title> <para> - A class is a collection of resources applied to a node with a single include statement. It groups together a comprehensible set of resources. A class <emphasis>ypclient</emphasis> would manage the <code>File["/etc/nsswitch.conf"]</code>, <code>File["/etc/yp.conf"]</code>, <code>Package["ypbind"]</code>, and <code>Service["ypbind"]</code> resources. + A class is a collection of resources applied to a node with a single <code>include</code> statement. It groups together a comprehensible set of resources. A class <emphasis>yp::client</emphasis> would manage the <code>File["/etc/nsswitch.conf"]</code>, <code>File["/etc/yp.conf"]</code>, <code>Package["ypbind"]</code>, and <code>Service["ypbind"]</code> resources. </para> </formalpara> </listitem> @@ -795,7 +796,7 @@ FIXME: </formalpara> <warning> <para> - The time on both the puppetmaster and the puppet must be within 5 minutes of eachother as the certificate generated and signed has a validity period. If the difference in time of these two nodes is more then 5 minutes, you will get a "Certificates not trusted" type of error. + The time on both the puppetmaster and the puppet cannot vary more then 5 minutes as the certificate generated by the puppet and signed by the puppetca has a validity period. The start time of this validity period is of importance as the validity period has to have at least started by the time the puppet uses the certificate --or else the signed certificate is considered invalid. If the difference in time of these two nodes is more then 5 minutes, you will get a "Certificates not trusted" type of error. </para> </warning> </listitem> @@ -803,7 +804,7 @@ FIXME: <formalpara> <title>The puppet generates all the facts</title> <para> - Most configurations rely on client information to make decisions. When the Puppet client starts, it loads the Facter Ruby library, collects all of the facts that it can, and passes those facts to the interpreter. When you use Puppet over a network, these facts are passed over the network to the server and the server uses them to compile the client's configuration. + Most configurations rely on client information to make decisions. When the Puppet client starts, it loads the Facter Ruby library, collects all the facts it can, and passes those facts to the interpreter. When you use Puppet over a network, these facts are passed over the network to the server and the server uses them to compile the client's configuration. </para> </formalpara> </listitem> @@ -1110,9 +1111,12 @@ debug: Calling fileserver.describe</screen> <formalpara> <title>certname</title> <para> - The puppetmaster certificate's Common Name (CN), for which by default the system's hostname is used. The hostname of the system is a pretty reasonable value. + The puppetmaster certificate's Common Name (CN), for which by default the system's hostname is used. The fully qualified domain name of the system is a pretty reasonable value. </para> </formalpara> + <para> + <screen>$ <userinput>hostname</userinput></screen> + </para> </listitem> <listitem> <formalpara> @@ -1209,6 +1213,13 @@ debug: Calling fileserver.describe</screen> </para> </section> + <section id="PuppetWorkshop-SettingUpPuppet-Configuration-Puppetmaster-Fileserver"> + <title>Configuring the fileserver</title> + <para> + Configuring the fileserver is more accurately described in <xref linkend="PuppetWorshop-HowToUsePuppet-Fileserver-Operations" />. + </para> + </section> + <section id="PuppetWorkshop-SettingUpPuppet-Configuration-Puppetmaster-Sitepp"> <title>Minimal site.pp</title> <para> @@ -1227,7 +1238,7 @@ node default { <section id="PuppetWorkshop-SettingUpPuppet-Configuration-Puppetmaster-ServiceConfiguration"> <title>Service Configuration</title> <para> - On Red Hat based systems, use <filename>/etc/sysconfig/puppetmaster</filename> to configure the service. It has three variables set, of which <code>PUPPETMASTER_MANIFEST</code> needs to point to the default manifest to use. + On Red Hat based systems, use <filename>/etc/sysconfig/puppetmaster</filename> to configure the service. It has three variables set, of which <code>PUPPETMASTER_MANIFEST</code> needs to point to the default manifest to use. Change the default only if you are not going to use environment specific </para> </section> @@ -1292,6 +1303,9 @@ node default { } }</screen> </para> + <para> + Puppet on a Debian system will now direct the package manager to install "openssh-client", while on other systems, the package manager is told to install "openssh-clients". + </para> <important> <para> Note that the name of this resource is now conditional, and thus virtually unpredictable from within the rest of the manifests, but still if you wanted to require the OpenSSH Client package you do not need to conditionally require the resource, but instead can use the title of the resource, "openssh-clients". @@ -1740,6 +1754,44 @@ class apache-ssl inherits apache { <para> Make sure you put the files and directories in place before restarting the puppetmaster service. </para> + + <section id="PuppetWorkshop-HowToUsePuppet-Environments-SettingUpEnvironments-ClientConfiguration"> + <title>Client Configuration</title> + <para> + Setting the environment the puppet gets it's configuration from is three-fold. + </para> + <para> + <orderedlist> + <listitem> + <para> + The environment you want to run the puppet in needs to be a valid environment, and besides default valid environments <emphasis>development</emphasis> and <emphasis>production</emphasis>, additional environments need to be configured using the <literal>environments</literal> setting in the <code>[puppetd]</code> section of <filename>/etc/puppet/puppet.conf</filename>: + </para> + <para> + <screen>[puppetd] + environments = development<replaceable>,testing</replaceable>,production</screen> + </para> + </listitem> + <listitem> + <para> + You can set the environment the puppet normally runs against with the <literal>environment</literal> setting in the <code>[puppetd]</code> section: + </para> + <para> + <screen>[puppetd] + environment = <replaceable>production</replaceable></screen> + </para> + <para> + The default environment for a puppet is <emphasis>production</emphasis> + </para> + </listitem> + <listitem> + <para> + The environment can be specified using the <code>--environment</code> command-line option to <application>puppetd</application>. + </para> + </listitem> + </orderedlist> + </para> + </section> + </section> </section> @@ -2260,11 +2312,19 @@ end</screen> storeconfigs = true dbadapter = mysql dbserver = <replaceable>127.0.0.1</replaceable> - dbuser = <replaceable>puppet</replaceable> - dbpassword = <replaceable>puppet</replaceable> + dbuser = <replaceable>puppetuser</replaceable> + dbpassword = <replaceable>password</replaceable> [dbsocket = /var/lib/mysql/mysql.sock] </screen> </para> + <para> + And create the database: + </para> + <para> + <screen># <userinput>mysql -p -e "CREATE DATABASE <replaceable>puppetdb</replaceable>;"</userinput> +# <userinput>mysql -p -e "GRANT ALL PRIVILEGES on <replaceable>puppetdb</replaceable>.* + to <replaceable>puppetuser@localhost</replaceable> identified by '<replaceable>password</replaceable>';"</userinput></screen> + </para> </section> <section id="PuppetWorkshop-SettingUpPuppet-Configuration-DatabaseServer-Postgresql"> @@ -2279,22 +2339,22 @@ end</screen> <screen>[puppetmasterd] storeconfigs = true dbadapter = postgresql - dbuser = <replaceable>puppet</replaceable> + dbuser = <replaceable>puppetuser</replaceable> dbpassword = <replaceable>password</replaceable> dbserver = <replaceable>localhost</replaceable> - dbname = <replaceable>puppet</replaceable></screen> + dbname = <replaceable>puppetdb</replaceable></screen> </para> <para> And create the database: </para> <para> <screen># <userinput>su - postgres</userinput> -$ <userinput>psql template1</userinput> -template1=# <userinput>create database <replaceable>puppet</replaceable>;</userinput> +$ <userinput>psql</userinput> +postgres=# <userinput>create database <replaceable>puppetdb</replaceable>;</userinput> CREATE DATABASE -<userinput>create user <replaceable>puppetuser</replaceable> with unencrypted password '<replaceable>password</replaceable>';</userinput> +postgres=# <userinput>create user <replaceable>puppetuser</replaceable> with unencrypted password '<replaceable>password</replaceable>';</userinput> CREATE ROLE -template1=# <userinput>grant create on database <replaceable>puppet</replaceable> to <replaceable>puppetuser</replaceable>;</userinput> +postgres=# <userinput>grant create on database <replaceable>puppetdb</replaceable> to <replaceable>puppetuser</replaceable>;</userinput> </screen> </para> </section> @@ -2522,7 +2582,7 @@ file { "/etc/httpd/conf/httpd.conf": <formalpara> <title>Services</title> <para> - This is kind of on a par with grouping, but the design concept behind it is different. Instead of grouping together the same kind of hardwareclass, group together the common function these nodes have. + This is kind of on a par with grouping, but the design concept behind it is different. Instead of grouping together the same kind of hardwareclass, group together the common function these nodes have. </para> </formalpara> <para> @@ -2559,6 +2619,8 @@ file { "/etc/httpd/conf/httpd.conf": <xi:include href="Appendix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + </book> <!-- Local variables: diff --git a/en-US/Courses.xml b/en-US/Courses.xml index b250580..2bc4859 100644 --- a/en-US/Courses.xml +++ b/en-US/Courses.xml @@ -183,4 +183,6 @@ <xi:include href="Books/Workshops/PuppetWorkshop/Puppet_Workshop.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Books/Workshops/DeployingLinux/Deploying_Linux.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + </set>

15 years, 5 months

1
0
0 / 0

← Newer
1
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

courses-commits November 2008