6:38 p.m.
Workshops/DeployingLinux/en-US/Appendix.xml | 26 -
Workshops/DeployingLinux/en-US/Deploying_Linux.xml | 376 +++++++++++++++++++-
Workshops/DeployingLinux/en-US/Revision_History.xml | 2
Workshops/PuppetWorkshop/en-US/Revision_History.xml | 2
en-US/Books/ClassRoom/Manual-Appendix.xml | 78 ++++
en-US/Books/ClassRoom/Manual.xml | 2
6 files changed, 450 insertions(+), 36 deletions(-)
New commits:
commit ac6c14263394efb98ae247892f369def2bb68436
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Tue Dec 2 01:38:34 2008 +0100
Updates
diff --git a/Workshops/DeployingLinux/en-US/Appendix.xml
b/Workshops/DeployingLinux/en-US/Appendix.xml
index ca88d80..07d82f2 100644
--- a/Workshops/DeployingLinux/en-US/Appendix.xml
+++ b/Workshops/DeployingLinux/en-US/Appendix.xml
@@ -93,34 +93,22 @@ options
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;
+ forwarders {
+ <replaceable>1.1.1.1</replaceable>;
};
-};
-include "/etc/named.root.hints";
+};
-zone "<replaceable>contoso.com</replaceable>" {
+zone "<replaceable>example.org</replaceable>" {
type master;
allow-update { 127.0.0.1; };
- file "dynamic/<replaceable>contoso.com</replaceable>.zone";
+ file "dynamic/<replaceable>example.org</replaceable>.zone";
};
-zone "<replaceable>2.2.2</replaceable>.in-addr.arpa" {
+zone "<replaceable>1.168.192</replaceable>.in-addr.arpa" {
type master;
allow-update { 127.0.0.1; };
- file
"dynamic/<replaceable>2.2.2</replaceable>.in-addr.arpa.zone";
+ file
"dynamic/<replaceable>1.168.192</replaceable>.in-addr.arpa.zone";
};
include "/etc/rndc.key";</screen>
diff --git a/Workshops/DeployingLinux/en-US/Deploying_Linux.xml
b/Workshops/DeployingLinux/en-US/Deploying_Linux.xml
index aa615a5..1c03b1c 100644
--- a/Workshops/DeployingLinux/en-US/Deploying_Linux.xml
+++ b/Workshops/DeployingLinux/en-US/Deploying_Linux.xml
@@ -12,7 +12,7 @@
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.
+ 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,
including it's version number, 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.
@@ -20,7 +20,7 @@
<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).
+ In this workshop, we will use PXE to provision systems. Using PXE has a
few 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>
@@ -123,15 +123,27 @@
<section id="DeployingLinux-HowThisWorks-UsingCdrom">
<title>Using a CD-ROM (set) or DVD (set)</title>
<para>
- para
+ You can perform automated installations using a CD or DVD, but you will
need physical access to the machine in order to put in the media, tell the system to boot
from the media, and possibly start the installation.
+ </para>
+ <para>
+ Additionally, regardless of whether you use a distribution that uses
kickstart, preseed or autoyast, you would either need to include the automated
installation configuration file on the media or make it available in a central location
and edit the isolinux menu to perform the installation procedure using that kickstart
file.
+ </para>
+ <para>
+ Updating the kickstart file if you have put it on the media would mean
you would have to burn the media each time you change the kickstart file, which isn't
very efficient nor flexible.
+ </para>
+ <para>
+ When putting the kickstart in a central location like a webserver, you
eliminate that one single factor that causes you to burn and burn again the ISO to disc,
but does not allow you to create several menu entries corresponding to different
installation profiles, or you would have to burn the updated ISO once more, making it less
efficient then the PXE alternative.
+ </para>
+ <para>
+ Alternatively, you would manually type the URI to the automated
installation configuration file whenever you boot and want to install a system.
</para>
- <section
id="DeployingLinux-HowThisWorks-UsingCdrom-CreatingACdrom">
+<!-- <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>-->
</section>
@@ -215,9 +227,10 @@
<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" />.
+ Example configuration for your dhcp and named server can be found in
<xref linkend="DeployingLinux-Appendix-DhcpConfiguration" /> and <xref
linkend="DeployingLinux-Appendix-NamedConfiguration" />.
</para>
<note>
+ <title>In this Workshop</title>
<para>
The sample configuration files in the Appendices are for reference.
Cobbler is going to manage the DHCP server and Named server.
</para>
@@ -234,7 +247,7 @@
<formalpara>
<title><userinput>cobbler
check</userinput></title>
<para>
- Have cobbler check what else you may need to pay
attention to. Very useful diagnostic tool.
+ Have cobbler check what else you may need to pay
attention to. Very useful diagnostic tool, as it lists what else you may need to do to get
cobbler up and running.
</para>
</formalpara>
</listitem>
@@ -271,25 +284,282 @@
<section
id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration">
<title>Configuring Cobbler</title>
<para>
- This section
+ This section helps you configure Cobbler.
</para>
+ <section
id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-EnablingServices">
+ <title>Enabling the Appropriate Services</title>
+ <indexterm>
+ <primary>Services</primary>
+ <secondary>Enabling the Appropriate</secondary>
+ </indexterm>
+ <para>
+ The Package Guidelines for Fedora and Red Hat mandate that no
(network) services may be enabled by default for security reasons. As such, you will need
to manually enable and start the appropriate services for a Cobbler environment.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <formalpara>
+ <title>tftp</title>
+ <para>
+ The TFTP server is actually a
<application>xinetd</application> service, and as such only needs to be
enabled rather then started.
+ </para>
+ </formalpara>
+ <para>
+ <screen># <userinput>chkconfig tftp
on</userinput></screen>
+ </para>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>xinetd</title>
+ <para>
+ <screen># <userinput>service xinetd
start</userinput>
+Starting xinetd: [ OK ]
+# <userinput>chkconfig xinetd on</userinput></screen>
+ </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>dhcpd</title>
+ <para>
+ <!--
+ FIXME
+
+ - Check if configuration of the dhcp service is
required, or that cobbler itself takes care of such
+ -> The installation of dhcp is not required;
cobbler only manages dhcp optionally
+ //-->
+ The ISC DHCP service is started by cobbler on sync, but
you will need to enable the service to start on boot yourself.
+ </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>named</title>
+ <para>
+ <!--
+ FIXME
+
+ - Check if configuration of the dhcp service is
required, or that cobbler itself takes care of such
+ -> The installation of dhcp is not required;
cobbler only manages dhcp optionally
+ //-->
+ The ISC DHCP service is started by cobbler on sync, but
you will need to enable the service to start on boot yourself.
+ </para>
+ </formalpara>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>httpd</title>
+ <para>
+ The Apache webserver is required for Cobbler to enable
kickstart installations as well as the administration web-interface.
+ </para>
+ </formalpara>
+ <para>
+ To start the Apache webserver and enable the service to start
on boot:
+ </para>
+ <para>
+ <screen># <userinput>service httpd
start</userinput>
+Starting httpd: [ OK ]
+# <userinput>chkconfig httpd on</userinput></screen>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
<section
id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDhcp">
<title>Manage DHCP</title>
+ <indexterm>
+ <primary>DHCP</primary>
+ <secondary>Configuring Cobbler to manage</secondary>
+ </indexterm>
+ <para>
+ Cobbler can manage the DHCP environment in terms of adding host
declarations to the subnet scope and setting the appropriate values to the configuration
of the DHCP server to enable BOOTP.
+ </para>
+ <para>
+ Cobbler can manage two types of DHCP servers: The ISC DHCP server,
and <application>dnsmasq</application>. Where
<application>dnsmasq</application> may be ideal under specific circumstances
such as provisioning virtualized systems, ISC DHCP is the de-facto standard in the
industry and allows large-scale environments as well as integration into your current
network environment -better then <application>dnsmasq</application>.
+ </para>
+ <note>
+ <title>In this Workshop</title>
+ <para>
+ In this workshop, we choose to manage the ISC DHCP server.
+ </para>
+ </note>
<para>
- para
+ To have Cobbler manage the DHCP server, set the following value in
<filename>/etc/cobbler/settings</filename> to
<literal>1</literal>:
+ </para>
+ <para>
+ <screen>manage_dhcp: 1</screen>
+ </para>
+ <formalpara>
+ <title>OMAPI</title>
+ <para>
+ OMAPI allows realtime DHCP updates without restarting or
reloading the ISC DHCP server. However, if enabled, a <literal>cobbler
sync</literal> will not restart the DHCP server. Because in your environment, you
need to edit the DHCP server settings template, you are advised to turn the use of OMAPI
off.
+ </para>
+ </formalpara>
+ <para>
+ To turn the use of OMAPI off, edit the following setting in
<filename>/etc/cobbler/settings</filename>:
+ </para>
+ <para>
+ <screen>omapi_enabled: 0</screen>
+ </para>
+ <formalpara>
+ <title>Configuring the DHCP Network Environment</title>
+ <para>
+ Now that Cobbler is configured to manage the ISC DHCP server, you
need to configure a <emphasis>template</emphasis> that Cobbler can then use to
create <filename>/etc/dhcpd.conf</filename> from. This template lives in
<filename>/etc/cobbler/dhcp.template</filename>.
+ </para>
+ </formalpara>
+ <para>
+ The default network for the Cobbler managed ISC DHCP server is
<literal>192.168.1.0/24</literal>. Edit
<filename>/etc/cobbler/dhcp.template</filename> to choose your network(s) or
subnet(s) the DHCP server should be authoritative for.
+ </para>
+ <note>
+ <title>In this Workshop</title>
+ <para>
+ In this workshop, we have configured the Cobbler server so that
the network connected to the client is <literal>192.168.1.0/24</literal> and
so the default subnet for the Cobbler managed ISC DHCP server is correct. Note however,
the <emphasis>option routers</emphasis> is set to
<literal>192.168.1.5</literal> while the actual router is the Cobbler server
with an IP address of <literal>192.168.1.1</literal>.
+ </para>
+ </note>
+ <para>
+ After you have configured Cobbler to manage the ISC DHCP server,
disabled OMAPI, and configured the appropriate router option, you can continue to
configuring Cobbler to <xref
linkend="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDns"
/>.
</para>
</section>
<section
id="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDns">
<title>Manage DNS</title>
+ <indexterm>
+ <primary>DNS</primary>
+ <secondary>Configuring Cobbler to manage</secondary>
+ </indexterm>
+ <para>
+ Cobbler can manage the DNS environment in terms of adding host
addresses to the domain and reverse domain zones and setting the appropriate values to the
configuration of the nameserver.
+ </para>
<para>
- para
+ Cobbler can manage two types of DNS servers: The ISC BIND server, and
<application>dnsmasq</application>. Where
<application>dnsmasq</application> may be ideal under specific circumstances
such as provisioning virtualized systems, ISC BIND is the de-facto standard in the
industry and allows large-scale environments as well as integration into your current
network environment -better then <application>dnsmasq</application>.
+ </para>
+ <note>
+ <title>In this Workshop</title>
+ <para>
+ In this workshop, we choose to manage the ISC DNS forward and
reverse zones for <literal>example.com</literal> and
<literal>192.168.1.0/24</literal>.
+ </para>
+ </note>
+ <para>
+ To have Cobbler manage the DNS server, set the following value in
<filename>/etc/cobbler/settings</filename> to
<literal>1</literal>:
+ </para>
+ <para>
+ <screen>manage_dns: 1</screen>
+ </para>
+ <formalpara>
+ <title>Configuring the DNS Server</title>
+ <para>
+ <!--
+ FIXME
+
+ - Check the actual location of the zone files that Cobbler
uses / manages
+ //-->
+ Now that Cobbler is configured to manage the ISC BIND DNS server,
you need to configure a <emphasis>template</emphasis> that Cobbler can then
use to create <filename>/etc/named.conf</filename> and
<filename>/var/named/dynamic/<replaceable>example.com</replaceable>.zone</filename>
from. The templates live in <filename>/etc/cobbler/named.template</filename>
and <filename>/etc/cobbler/zone.template</filename>.
+ </para>
+ </formalpara>
+ <para>
+ <!--
+ FIXME
+
+ - Check calling the reverse zone to manage:
1.168.192.in-addr.arpa vs. 192.168.1
+ //-->
+ There is no default zone that Cobbler manages. You will need to
configure the (forward) domain namespace for Cobbler, as well as the reverse lookup zones
to manage.
+ </para>
+ <para>
+ To configure the following settings in
<filename>/etc/cobbler/settings</filename>:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara>
+ <title>manage_forward_zones</title>
+ <para>
+ A list of forward zones to manage.
+ </para>
+ </formalpara>
+ <para>
+ The list is a Python-style list, and the syntax is as
follows:
+ </para>
+ <para>
+ <screen>manage_forward_zones: [
+ '<replaceable>example.org</replaceable>',
+ '<replaceable>contoso.com</replaceable>'
+ ]</screen>
+ </para>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>manage_reverse_zones</title>
+ <para>
+ <!--
+ FIXME
+
+ - Check if this *needs* to be '192.168.1'
as mentioned in the examples in upstream documentation, or whether this can be
'1.168.192.in-addr.arpa', which is preferable.
+ //-->
+ A list of reverse zones to manage.
+ </para>
+ </formalpara>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <note>
+ <title>In this Workshop</title>
+ <para>
+ For the Cobbler managed ISC BIND DNS server, configure a
forwarder to allow the client to resolve names outside of the network's domain name
space. The configuration snippet to put in
<filename>/etc/cobbler/named.template</filename>:
+ </para>
+ <para>
+ <screen>options {
+ ... lines removed ...
+ forwarders {
+ 1.1.1.1;
+ };
+ ... lines removed ...
+};</screen>
+ </para>
+ </note>
+ <important>
+ <title>Default Named Options</title>
+ <para>
+ For various reasons, the default named options include the
following settings:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>listen-on port 53 { 127.0.0.1;
};</literal>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>allow-query { localhost;
};</literal>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </important>
+ <para>
+ After you have configured Cobbler to manage the ISC DHCP server,
disabled OMAPI, and configured the appropriate router option, you can continue to
configuring Cobbler to <xref
linkend="DeployingLinux-InstallingAndConfiguringCobbler-Configuration-ManageDns"
/>
</para>
</section>
</section>
+ <section id="DeployingLinux-ReloadingTheConfiguration">
+ <title>Reloading the Configuration</title>
+ <indexterm>
+ <primary>Configuration</primary>
+ <secondary>Reloading Configuration Changes</secondary>
+ </indexterm>
+ <para>
+ Cobbler needs to synchronize between it's settings
(<filename>/etc/cobbler/settings</filename>) and the runtime environment (in
this case <filename>/etc/named.conf</filename> and various zone files in
<filename>/var/named/dynamic</filename>). Order Cobbler to synchronize:
+ </para>
+ <para>
+ <screen># <userinput>cobbler
sync</userinput></screen>
+ </para>
+ <para>
+ You will see the named and dhcpd services restart.
+ </para>
+ </section>
+
</chapter>
<chapter id="DeployingLinux-PerformingAutomatedInstallations">
@@ -297,27 +567,107 @@
<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>
+<!-- <note>
+ <title>In this Workshop</title>
+ <para>
+ para
+ </para>
+ </note>-->
<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>
+
+ <formalpara>
+ <title>Kickstart Configuration File Syntax</title>
+ <para>
+ A kickstart consists of two mandatory, and two optional
<emphasis>sections</emphasis>. The first mandatory section is the
<emphasis>settings</emphasis>, the second is
<emphasis>%packages</emphasis> section.
+ </para>
+ </formalpara>
+ <para>
+ A very simple kickstart looks similar to the following:
+ </para>
+ <para>
+ <screen># The <emphasis>settings</emphasis> section:
+#platform=x86, AMD64, or Intel EM64T
+# System authorization information
+auth --useshadow --enablemd5
+# System bootloader configuration
+bootloader --location=mbr
+# Partition clearing information
+clearpart --all --initlabel
+# Use text mode install
+text
+(...lines removed...)
+# Reboot after installation
+reboot
+
+# The <emphasis>%packages</emphasis> section:
+%packages
+foo
+bar
+%end</screen>
+ </para>
+ <para>
+ The first section concerns system settings and actually answer questions
the installation procedure may have.
+ </para>
+ <para>
+ The second section also concerns a stage in the installation procedure;
package selection. In this section, you select and unselect packages, and include groups
of packages to be installed:
+ </para>
+ <para>
+ <screen># I'm thinking we definitely need a kernel
+kernel
+# We don't want beagle
+-beagle
+# Include a graphical desktop environment
+@base-x
+@gnome-desktop</screen>
+ </para>
+ <para>
+ The <application>system-config-kickstart</application>
program can help you set up a kickstart by allowing you to click through the available
options and possible values.
+ </para>
+ <para>
+ A few example kickstarts are listed in <xref
linkend="DeployingLinux-Appendix-Kickstart" />.
+ </para>
+ <!--
+ FIXME
+
+ - Refer to upstream website and documentation
+ //-->
</section>
<section
id="DeployingLinux-PerformingAutomatedInstallations-DebianAndUbuntu">
<title>Debian and Ubuntu</title>
<para>
- preseed
+ Both distributions use a utility called
<application>debconf</application>, that can handle
<emphasis>preseed</emphasis> files which essentially do exactly as they say;
preseed the anwers to the questions debconf may have.
+ </para>
+ <para>
+ Any particular line in a preseed may look similar to:
+ </para>
+ <para>
+ <screen>d-i partman-auto/confirm boolean true</screen>
+ </para>
+ <para>
+ The first keyword, <literal>d-i</literal> indicates the
application debconf should use this line for. In this case,
<literal>d-i</literal> is short for debian-installer.
+ </para>
+ <para>
+ The second keyword describes a <emphasis>category</emphasis>
and <emphasis>question</emphasis>. In this case, the category is automatically
partitioning, and the question is whether we want to confirm the autopartitioning the
Debian Installer performs; <emphasis>true</emphasis> means we're saying:
"Yes, confirmed" (not "Yes, we need to confirm please").
</para>
</section>
+<!--
<section
id="DeployingLinux-PerformingAutomatedInstallations-SuseAndOpensuse">
<title>SUSE and openSUSE</title>
<para>
- autoyast
+ <!-
+ FIXME
+ //->
+ autoyast is a beast
</para>
</section>
+//-->
</chapter>
<chapter id="DeployingLinux-ProvisionedSystemInitialConfiguration">
@@ -329,6 +679,6 @@
<xi:include href="Appendix.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
-<!-- <index />-->
+ <index />
</book>
diff --git a/Workshops/DeployingLinux/en-US/Revision_History.xml
b/Workshops/DeployingLinux/en-US/Revision_History.xml
index 68432a0..1fef357 100644
--- a/Workshops/DeployingLinux/en-US/Revision_History.xml
+++ b/Workshops/DeployingLinux/en-US/Revision_History.xml
@@ -2,7 +2,7 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<appendix id="appe-Publican-Revision_History">
+<appendix id="DeployingLinux-Appendix-Revision_History">
<title>Revision History</title>
<simpara>
<revhistory>
diff --git a/Workshops/PuppetWorkshop/en-US/Revision_History.xml
b/Workshops/PuppetWorkshop/en-US/Revision_History.xml
index 68432a0..e5427c3 100644
--- a/Workshops/PuppetWorkshop/en-US/Revision_History.xml
+++ b/Workshops/PuppetWorkshop/en-US/Revision_History.xml
@@ -2,7 +2,7 @@
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<appendix id="appe-Publican-Revision_History">
+<appendix id="PuppetWorkshop-Appendix-Revision_History">
<title>Revision History</title>
<simpara>
<revhistory>
diff --git a/en-US/Books/ClassRoom/Manual-Appendix.xml
b/en-US/Books/ClassRoom/Manual-Appendix.xml
index 4b2e422..2667ea2 100644
--- a/en-US/Books/ClassRoom/Manual-Appendix.xml
+++ b/en-US/Books/ClassRoom/Manual-Appendix.xml
@@ -4,7 +4,7 @@
<part id="ClassRoomManual-Appendices">
<title>Appendices</title>
- <appendix id="ClassRoomManual-AppendixA">
+ <appendix
id="ClassRoomManual-Appendix-Cisco_Switch_Configuration_Example">
<title>Default Cisco Switch Configuration Example</title>
<para>
The following is an example configuration for a 24-port Cisco switch for use
with a default classroom setup.
@@ -273,5 +273,81 @@ exit
</screen>
</para>
</appendix>
+
+ <appendix id="ClassRoomManual-Appendix-VLANs">
+ <title>Switch VLAN Overview</title>
+ <para>
+ <segmentedlist>
+ <segtitle>VLAN #</segtitle>
+ <segtitle>Description</segtitle>
+ <segtitle>Suggested IP Range</segtitle>
+ <segtitle>Router?</segtitle>
+ <segtitle>DHCP Server?</segtitle>
+ <seglistitem>
+ <seg>1</seg>
+ <seg>Default VLAN</seg>
+ <seg>1.1.1.0/24</seg>
+ <seg>1.1.1.1</seg>
+ <seg>Yes</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>111</seg>
+ <seg>"Uplink" VLAN. Use in conjunction with VLAN
112</seg>
+ <seg>2.11.1.0/24</seg>
+ <seg>2.11.1.1</seg>
+ <seg>Yes</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>112</seg>
+ <seg>Client-Server VLAN. Use in conjunction with VLAN
111</seg>
+ <seg>2.11.2.0/24</seg>
+ <seg>No, suggest 2.11.2.1</seg>
+ <seg>No, server runs DHCP Server</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>121</seg>
+ <seg>"Uplink" VLAN. Use in conjunction with VLAN
122</seg>
+ <seg>2.12.1.0/24</seg>
+ <seg>2.12.1.1</seg>
+ <seg>Yes</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>122</seg>
+ <seg>Client-Server VLAN. Use in conjunction with VLAN
121</seg>
+ <seg>2.12.2.0/24</seg>
+ <seg>No, suggest 2.12.2.1</seg>
+ <seg>No, server runs DHCP Server</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>131</seg>
+ <seg>"Uplink" VLAN. Use in conjunction with VLAN
132</seg>
+ <seg>2.13.1.0/24</seg>
+ <seg>2.13.1.1</seg>
+ <seg>Yes</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>132</seg>
+ <seg>Client-Server VLAN. Use in conjunction with VLAN
131</seg>
+ <seg>2.13.2.0/24</seg>
+ <seg>No, suggest 2.13.2.1</seg>
+ <seg>No, server runs DHCP Server</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>141</seg>
+ <seg>"Uplink" VLAN. Use in conjunction with VLAN
142</seg>
+ <seg>2.14.1.0/24</seg>
+ <seg>2.14.1.1</seg>
+ <seg>Yes</seg>
+ </seglistitem>
+ <seglistitem>
+ <seg>142</seg>
+ <seg>Client-Server VLAN. Use in conjunction with VLAN
141</seg>
+ <seg>2.14.2.0/24</seg>
+ <seg>No, suggest 2.14.2.1</seg>
+ <seg>No, server runs DHCP Server</seg>
+ </seglistitem>
+ </segmentedlist>
+ </para>
+ </appendix>
<xi:include href="Revision_History.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
diff --git a/en-US/Books/ClassRoom/Manual.xml b/en-US/Books/ClassRoom/Manual.xml
index bc74f4b..8c703b3 100644
--- a/en-US/Books/ClassRoom/Manual.xml
+++ b/en-US/Books/ClassRoom/Manual.xml
@@ -164,7 +164,7 @@
The default VLAN for any given switchport is 1. This is the
factory default setup for a switch and will work for most basic courses, but since all the
PCs have been connected using both NICs, we're going to disable one of the switchports
for each of the PCs. This is where the odd/even switchport numbering kicks in. If you
connect the PC's NICs consistently, you'll never have to question which PC is
connected to which ports exactly, and you'll know which port is supposed to be
disabled in the default setup.
</para>
<para>
- You can find an example default configuration file for a Cisco
24-port switch in <ulink url="ClassRoomManual-AppendixA.html">Appendix A:
Default Cisco Switch Configuration Example</ulink>.
+ You can find an example default configuration file for a Cisco
24-port switch in <xref
linkend="ClassRoomManual-Appendix-Cisco_Switch_Configuration_Example" />.
Additionally, you can find an overview of different VLANs to configure in <xref
linkend="ClassRoomManual-Appendix-VLANs" />.
</para>
</section>