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

[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&gt;
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&gt;j.van.meeuwen(a)ogd.nl&lt;/email&gt;
-    </author>
-    <author>
-        <firstname>Stefan</firstname>
-        <surname>Hartsuiker</surname>
-        <affiliation>
-            <orgname>Operator Groep Delft</orgname>
-            <orgdiv>System Engineer</orgdiv>
-        </affiliation>
-        <email&gt;s.hartsuiker(a)ogd.nl&lt;/email&gt;
-    </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/&q...
/></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/&q...
/></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&gt;dude.mcdude(a)myorg.org&lt;/email&gt;
-	</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&gt;j.van.meeuwen(a)ogd.nl&lt;/email&gt;
+    </author>
+    <author>
+        <firstname>Stefan</firstname>
+        <surname>Hartsuiker</surname>
+        <lineage>RHCE</lineage>
+        <affiliation>
+            <jobtitle>System Engineer</jobtitle>
+            <orgname>Operator Groep Delft</orgname>
+        </affiliation>
+        <email&gt;s.hartsuiker(a)ogd.nl&lt;/email&gt;
+    </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>
+<!--
+    <productname>Workshop</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.png" />
+            </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" />
 </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/&q...
/></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/&q...
/></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-InstallingAndConfiguringAPxeEnvironment">
+        <title>Installing and Configuring A PXE Environment</title>
+        <para>
+            For comparison.
+        </para>
+    </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" />
+
+<!--    <index />-->
+</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 id="PuppetWorkshop-Preface-Acknowledgements">
-        <title>Acknowledgements</title>
+    <section id="PuppetWorkshop-Preface-AdboutThisDocument">
+        <title>About this Document</title>
         <para>
-            Foo
+            This document is licensed under the Open Publication License version 1.0,
which is available at <ulink url="http://www.opencontent.org/openpub/" />.
You can get the latest version from <ulink
url="http://www.kanarip.com/courses/puppet/puppet.pdf" />, and it's
sources live at <ulink
url="http://git.fedorahosted.org/git/courses.git?p=courses.git;a=tre...
/>.
         </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 &amp; 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 &amp;
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 &amp;
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" />
 
+<!--    <index />-->
+
 </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>