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