[Et-mgmt-commits-list] [SCM] Provisioning Made Simple branch, master now at v0.4.5-18-g2011201
Michael DeHaan
mdehaan at redhat.com
Wed Apr 4 16:36:08 UTC 2007
Hello,
This is an automated email from the git hooks/update script, it was
generated because a ref change was pushed to the repository.
Updating branch, master,
via 201120155d0a045fe1af77725c40e8f380b6182d (commit)
via 096b34a93a6e60602b7366fd7ae418ba4e399d97 (commit)
from 36918f5b0cc684618e5a0e0f84f7cc380f956195 (commit)
- Log -----------------------------------------------------------------
commit 201120155d0a045fe1af77725c40e8f380b6182d
Author: Michael DeHaan <mdehaan at mdehaan.rdu.redhat.com>
Date: Wed Apr 4 12:36:59 2007 -0400
Correct some errors in kickstart templating for the new repo stuff ...
commit 096b34a93a6e60602b7366fd7ae418ba4e399d97
Author: Michael DeHaan <mdehaan at mdehaan.rdu.redhat.com>
Date: Wed Apr 4 11:34:45 2007 -0400
Adding website content to git for backup.
-----------------------------------------------------------------------
Diffstat:
cobbler/action_sync.py | 5 +-
website/cobbler.html | 548 ++++++++++++++++++++++++++++
website/cobbler.odp | Bin
website/favicon.ico | Bin
website/img/black-red/callout-bg.png | Bin
website/img/black-red/content-left-bg.png | Bin
website/img/black-red/content-right-bg.png | Bin
website/img/black-red/hr.png | Bin
website/img/black-red/topbar-bg.png | Bin
website/img/black-red/topbar-graphic.png | Bin
website/index.html | 201 ++++++++++
website/koan.html | 70 ++++
website/push.sh | 6 +
website/style.css | 152 ++++++++
14 files changed, 980 insertions(+), 2 deletions(-)
diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py
index 1559b64..a00d82f 100644
--- a/cobbler/action_sync.py
+++ b/cobbler/action_sync.py
@@ -396,7 +396,8 @@ class BootSync:
# if there is only one, then there is no need to do this.
if len(distro.source_repos) > 1:
for r in distro.source_repos:
- buf = buf + "%s\n" % r
+ base = r.split("/")[-1].replace(".repo","")
+ buf = buf + "repo --name=%s --baseurl=%s\n" % (base, r)
return buf
@@ -418,7 +419,7 @@ class BootSync:
buf = buf + "wget %s --output-document=/etc/yum.repos.d/%s.repo\n" % (r, short)
# if there were any core repos, install the voodoo to disable the OS public core
- # location
+ # location -- FIXME: should probably run sed on the files, rather than rename them.
if len(distro.source_repos) > 0:
for x in ["fedora-core", "Centos-Base", "rhel-core"] :
buf = buf + "mv /etc/yum.repos.d/%s.repo /etc/yum.repos.d/disabled-%s\n" % (x,x)
diff --git a/website/cobbler.html b/website/cobbler.html
new file mode 100644
index 0000000..eb7d5ea
--- /dev/null
+++ b/website/cobbler.html
@@ -0,0 +1,548 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>NAME</title>
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body style="background-color: white">
+
+<p><a name="__index__"></a></p>
+<!-- INDEX BEGIN -->
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#cobbler_usage">COBBLER USAGE</a></li>
+ <ul>
+
+ <li><a href="#setup">SETUP</a></li>
+ <li><a href="#adding_a_distribution">ADDING A DISTRIBUTION</a></li>
+ <li><a href="#adding_a_profile">ADDING A PROFILE</a></li>
+ <li><a href="#adding_a_system">ADDING A SYSTEM</a></li>
+ <li><a href="#adding_a_repository_to_mirror">ADDING A REPOSITORY TO MIRROR</a></li>
+ <li><a href="#displaying_configuration_entries">DISPLAYING CONFIGURATION ENTRIES</a></li>
+ <li><a href="#deleting_configuration_entries">DELETING CONFIGURATION ENTRIES</a></li>
+ <li><a href="#rebuilding_configurations">REBUILDING CONFIGURATIONS</a></li>
+ </ul>
+
+ <li><a href="#examples">EXAMPLES</a></li>
+ <ul>
+
+ <li><a href="#import_workflow">IMPORT WORKFLOW</a></li>
+ <li><a href="#normal_workflow">NORMAL WORKFLOW</a></li>
+ <li><a href="#repository_mirroring_workflow">REPOSITORY MIRRORING WORKFLOW</a></li>
+ <li><a href="#xen">XEN</a></li>
+ </ul>
+
+ <li><a href="#advanced_topics">ADVANCED TOPICS</a></li>
+ <ul>
+
+ <li><a href="#pxe_menus">PXE MENUS</a></li>
+ <li><a href="#kickstart_templating">KICKSTART TEMPLATING</a></li>
+ <li><a href="#dhcp_configuration_management">DHCP CONFIGURATION MANAGEMENT</a></li>
+ <li><a href="#enchant">ENCHANT</a></li>
+ <li><a href="#importing_trees">IMPORTING TREES</a></li>
+ <li><a href="#default_pxe_boot_behavior">DEFAULT PXE BOOT BEHAVIOR</a></li>
+ <li><a href="#repo_management">REPO MANAGEMENT</a></li>
+ <li><a href="#kickstart_tracking">KICKSTART TRACKING</a></li>
+ <li><a href="#tweaking">TWEAKING</a></li>
+ <li><a href="#api">API</a></li>
+ </ul>
+
+ <li><a href="#exit_status">EXIT_STATUS</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+<!-- INDEX END -->
+
+<hr />
+<p>
+</p>
+<h1><a name="name">NAME</a></h1>
+<p>cobbler is a command line tool for configuring a provisioning and update server. It supports provisioning via PXE, virtualization (Xen), and remotely re-provisioning a existing Linux system when PXE booting isn't possible. The latter two features are enabled by usage of 'koan' (a client side provisioning application) on the remote system. Update server features include yum mirroring over rsync:// and integration of those mirrors with kickstart.</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p>cobbler command [subcommand] [--arg1=] [--arg2=]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>Cobbler manages provisioning using a tiered concept of Distributions, Profiles, Systems, and Repositories.</p>
+<p>Distributions contain information about what kernel and initrd are used, along with various other information, such as required kernel parameters.</p>
+<p>Profiles associate a Distribution with a kickstart file and optionally customize it further.</p>
+<p>Systems associate a hostname, IP, or MAC with a distribution and optionally customize the Profile further.</p>
+<p>Repositories contain yum mirror information. Using cobbler to mirror repositories is an optional/advanced
+feature and is covered further down in this manpage.</p>
+<p>The main advantages of cobbler is that it glues together a lot of disjoint technologies and concepts and abstracts the user from the need to understand them. It allows the systems administrator to concentrate on what he needs to do, and not how it is done.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p>For help in building kickstarts, try using the ``system-config-kickstart'' tool, or install a new system and look at the /root/anaconda-ks.cfg file left over from the installer. General kickstart questions can also be asked at <a href="mailto:kickstart-list at redhat.com.">kickstart-list at redhat.com.</a> Cobbler ships some kickstart templates in /etc/cobbler that may also prove helpful.</p>
+<p>
+</p>
+<hr />
+<h1><a name="cobbler_usage">COBBLER USAGE</a></h1>
+<p>
+</p>
+<h2><a name="setup">SETUP</a></h2>
+<p>Running ``cobbler check'' after installation will verify that cobbler's prerequisites are installed and configured correctly. This is a good first command to run after installing cobbler.</p>
+<p>Any problems detected should be corrected, with the potential exception of DHCP related warnings. Run ``cobbler sync'' after making any changes to the configuration files to ensure those changes are applied.</p>
+<p>It is especially important that the server name field be accurate in /var/lib/cobbler/settings, without this field being correct, kickstart trees may not be found, and provisioning won't work.</p>
+<p>For PXE, if DHCP is to be run from the cobbler server, the dhcp configuration file should be changed as suggested. If DHCP is not run locally, the ``next-server'' field on the DHCP server should point to the cobbler server's IP and the filename should be set to ``pxelinux.0''.</p>
+<p>Cobbler can also manage (generate) your dhcp configuration file -- this is covered in a later section. If you don't already have a dhcp setup, allowing cobbler to manage it may prove to be useful. If you already have a setup, moving an existing setup to be managed from within cobbler is relatively painless and is entirely optional.</p>
+<p>
+</p>
+<h2><a name="adding_a_distribution">ADDING A DISTRIBUTION</a></h2>
+<p>This first step towards configurating what you want to provision is to add a distribution to the cobbler's configuration.</p>
+<p>If there is an rsync mirror or filesystem tree that you would rather import instead, skip down to the documentation about the ``import'' command. It's really a lot easier, but it requires waiting for the mirror to sync data across, or using a mounted DVD (or DVD image) you might have lying around. Imported distros also save time during install since they don't have to hit external install sources.</p>
+<p>The manual distro add command is:</p>
+<p><strong>cobbler distro add --name=string --kernel=path --initrd=path [--kopts=string] [--ksmeta=string] [--arch=x86|x86_64|ia64] [--breed=redhat|suse]</strong></p>
+<dl>
+<dt><strong><a name="item_name">name</a></strong>
+
+<dd>
+<p>a string identifying the distribution, this should be something like ``rhel4''.</p>
+</dd>
+</li>
+<dt><strong><a name="item_kernel">kernel</a></strong>
+
+<dd>
+<p>an absolute filesystem path to a kernel image</p>
+</dd>
+</li>
+<dt><strong><a name="item_initrd">initrd</a></strong>
+
+<dd>
+<p>an absolute filesystem path to a initrd image</p>
+</dd>
+</li>
+<dt><strong><a name="item_kopts">kopts</a></strong>
+
+<dd>
+<p>(optional) sets kernel command-line arguments that the distro, and profiles/systems dependant
+on it, will use.</p>
+</dd>
+<dd>
+<p>Example: --kopts=``foo=bar baz=3 asdf''</p>
+</dd>
+</li>
+<dt><strong><a name="item_arch">arch</a></strong>
+
+<dd>
+<p>(optional) sets the architecture for the PXE bootloader</p>
+</dd>
+<dd>
+<p>x86 and x86_64 are interchangable, both use syslinux.</p>
+</dd>
+<dd>
+<p>ia64 uses the IA64 build of elilo.</p>
+</dd>
+<dd>
+<p>if you don't use IA64 systems, leaving this parameter off is fine.</p>
+</dd>
+</li>
+<dt><strong><a name="item_ksmeta">ksmeta</a></strong>
+
+<dd>
+<p>(optional)</p>
+</dd>
+<dd>
+<p>This is an advanced feature that sets kickstart variables to substitute, thus enabling kickstart files to be treated as templates.</p>
+</dd>
+<dd>
+<p>Example: --ksmeta=``foo=bar baz=3 asdf''</p>
+</dd>
+<dd>
+<p>See the section below on templating.</p>
+</dd>
+</li>
+<dt><strong><a name="item_breed">breed</a></strong>
+
+<dd>
+<p>Defaults to ``redhat'', which is a suitable value for Fedora and Centos as well. Specifying ``suse'' allows the kickstart file parameters to be treated instead like AutoYaST answer files, such that the proper parameters for SuSE answer files
+are put on the kernel command line. Support for other types of distributions is possible in the future. The file used for the answer file, regardless of
+distro breed, is the value used for --kickstart when creating the profile. See the profile add commands for further information.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="adding_a_profile">ADDING A PROFILE</a></h2>
+<p>A profile associates a distribution to additional specialized options, such as a kickstart automation file. Profiles are the core unit of provisioning and at least one profile must exist for every distribution to be provisioned. A profile might represent, for instance, a web server or desktop configuration.</p>
+<p><strong>cobbler profile add --name=string --distro=string [--kickstart=url] [--kopts=string] [--ksmeta=string] [--virt-name=string] [--virt-file-size=gigabytes] [--virt-ram=megabytes]</strong></p>
+<p>Arguments are as listed for distributions, except for the ``arch'' parameter, and with the additions listed below:</p>
+<dl>
+<dt><strong>name</strong>
+
+<dd>
+<p>a descriptive name. This could be something like ``rhel4webservers'' or ``fc6desktops''.</p>
+</dd>
+</li>
+<dt><strong><a name="item_distro">distro</a></strong>
+
+<dd>
+<p>the name of a previously defined cobbler distribution</p>
+</dd>
+</li>
+<dt><strong><a name="item_kickstart">kickstart</a></strong>
+
+<dd>
+<p>(optional) an HTTP URL, NFS URL, or local filesystem path to a kickstart file. Filesystem paths are needed to take advantage of cobbler's kickstart templating features and are therefore recommended. Kickstart templating is covered in a later section.</p>
+</dd>
+<dd>
+<p>If this parameter is not provided, the kickstart file will default to /etc/cobbler/default.ks (or whatever is set in /var/lib/cobbler/settings). This file is initially blank, meaning default kickstarts are not automated. Admins can change the default.ks or can leave it blank.</p>
+</dd>
+<dd>
+<p>Note: For other breeds of distros (see --breed argument to ``distro add'') that do not use ``kickstarts'', the kickstart in this case is just the distro specific answer file (such as an AutoYAST file). koan doesn't work for those other distros (like SuSE), but cobbler should be perfectly usable as a stand-alone solution for automated multi-distro-breed PXE control.</p>
+</dd>
+</li>
+<dt><strong><a name="item_virt_2dname">virt-name</a></strong>
+
+<dd>
+<p>(optional) (Virt-only) what the Virt guest name should start with. Creating
+multiple images on a machine will cause increasing numbers to be appended to this name. The default is ``virtguest''.</p>
+</dd>
+</li>
+<dt><strong><a name="item_virt_2dfile_2dsize">virt-file-size</a></strong>
+
+<dd>
+<p>(optional) (Virt-only) how large the disk image should be in gigabytes. The default is ``5''.</p>
+</dd>
+</li>
+<dt><strong><a name="item_virt_2dram">virt-ram</a></strong>
+
+<dd>
+<p>(optional) (Virt-only) how many megabytes of RAM to consume. The default is 512 MB.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="adding_a_system">ADDING A SYSTEM</a></h2>
+<p>Systems assign a piece of hardware with the cobbler profile to be assigned to it. Systems can be defined by hostname, IP, or MAC address. When available, use of the MAC address to assign systems is preferred.</p>
+<p><strong>cobbler system add --name=ip|mac|hostname --profile=string [--kopts=string] [--pxe-address=string] [--ksmeta=string]</strong></p>
+<p>Adds a cobbler System to the configuration. Arguments are specified as per ``profile add'' with
+the following changes:</p>
+<dl>
+<dt><strong>name</strong>
+
+<dd>
+<p>The system name must be either a currently-resolvable hostname, an IP address, or a MAC address.</p>
+</dd>
+<dd>
+<p>When defining Virtualized systems, using a MAC address causes the Virt MAC address to be used for creation,
+so that is the preferred usage. To restate this, unless you have a better reason, use the MAC
+address here, as it makes things a lot easier and more powerful across the board.</p>
+</dd>
+<dd>
+<p>There is also the magic name ``default'', which allows creation of the default PXE profile. Without
+a ``default'' system name created, PXE will fall through to local boot for unconfigured systems.</p>
+</dd>
+</li>
+<dt><strong><a name="item_pxe_2daddress">pxe-address</a></strong>
+
+<dd>
+<p>Advanced feature.</p>
+</dd>
+<dd>
+<p>If cobbler is configured to generate the dhcpd.conf file, use this
+setting to pin a certain hostname or IP to a given MAC address. This corresponds to the ``fixed-address'' field in dhcpd.conf.</p>
+</dd>
+<dd>
+<p>When using this setting for IA64 machines, be sure that the ``--name'' given to the ``system add'' command is a MAC address or no per-system record in dhcpd.conf can be generated.</p>
+</dd>
+<dd>
+<p>Example: ---pxe-address=192.168.1.50</p>
+</dd>
+<dd>
+<p>NOTE: Due to a limitation in elilo (IA64 bootloader), this parameter must ALSO be used even if dhcpd.conf files are not being managed by cobbler AND you want to PXE provision IA64 systems using a handwritten dhcpd.conf. Also, for IA64, the value of pxe-address must be an IP, and not a hostname, even though hostnames work for X86. Thankfully, if you don't have IA64 systems, there are a lot less rules.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="adding_a_repository_to_mirror">ADDING A REPOSITORY TO MIRROR</a></h2>
+<p>Repository mirroring is one of the more complex cobbler features, though if you want to mirror
+a yum repository and integrate it with your provisioning, cobbler can help simplify the required
+knowledge a good bit. If you're just provisioning your home system, ignore this part.</p>
+<p><strong>cobbler repo add --mirror=url --mirror-name=string [--local-filename=string]</strong></p>
+<dl>
+<dt><strong><a name="item_mirror">mirror</a></strong>
+
+<dd>
+<p>The addresss of the mirror. This needs to be either an rsync:// url or an ssh location usable with rsync.
+The mirror address should specify an exact repository to mirror -- just one architecture
+and just one distribution. If you have a seperate repo to mirror for a different arch, add that
+repo seperately.</p>
+</dd>
+<dd>
+<p>Here's an example of what looks like a good URL:</p>
+</dd>
+<dd>
+<p><a href="rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386">rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386</a> (for rsync protocol)
+<a href="mailto:user at yourmirror.example.com/fedora-linux-core/updates/6/i386">user at yourmirror.example.com/fedora-linux-core/updates/6/i386</a> (for SSH)</p>
+</dd>
+<dd>
+<p>To put it more simply, if the content you are mirroring doesn't contain rpm's
+at the top level of the URL, this is bad, and you need to specify a different value. Using the
+wrong mirror value here will rsync over too much data, and also the provisioning integration code
+simply won't work. You can't pass in a Fedora mirror, or even a FC6 mirror address. Be specific.</p>
+</dd>
+</li>
+<dt><strong><a name="item_mirror_2dname">mirror-name</a></strong>
+
+<dd>
+<p>This name is used as the save location for the mirror. If the mirror represented, say, Fedora Core
+6 i386 updates, a good name would be ``fc6i386updates''. Be explicit.</p>
+</dd>
+<dd>
+<p>This name corresponds with values given to the --repo parameter of ``cobbler profile add''. If a profile
+has a --repo value that matches the name here, that repo can be automatically set up during provisioning.
+This means that, if supported by Anaconda, the repo can be used during kickstart install -- and -- either way,
+it can be automatically configured on the clients.</p>
+</dd>
+</li>
+<dt><strong><a name="item_local_2dfilename">local-filename</a></strong>
+
+<dd>
+<p>Local filename specifies, for kickstarts containing the template parameter ``yum_config_stanza'',
+what files to populate on provisioned clients in /etc/yum.repos.d. In other words, if this value
+is ``foo'', the repo would be added on provisioned clients as ``/etc/yum.repos.d/foo.repo''. If you don't
+want clients to have this repo installed, don't add a name for the repo, and provisioned machines
+will not configure yum to know about this repo -- you can still do it manually if you choose.</p>
+</dd>
+<dd>
+<p>See /etc/cobbler/kickstart_fc6.ks for an example of how to employ this within a kickstart template.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="displaying_configuration_entries">DISPLAYING CONFIGURATION ENTRIES</a></h2>
+<p>This is a rather simple command, usable regardless of how you are using cobbler.</p>
+<p><strong>cobbler report [--settings] [--profiles] [--distros] [--systems] [--repos]</strong></p>
+<p>Prints the current cobbler configuration for systems, profiles, and groups. If one of the switches is given, only information for those is printed.</p>
+<p>The list command gives an abbreviated version of what ``report'' gives.
+It only returns the names of each item.</p>
+<p><strong>cobbler list [--settings] [--profiles] [--distros] [--systems] [--repos]</strong></p>
+<p>Alternatively, you could look at the configuration files in /var/lib/cobbler to see the same information.</p>
+<p>
+</p>
+<h2><a name="deleting_configuration_entries">DELETING CONFIGURATION ENTRIES</a></h2>
+<p>If you want to remove a specific object, use the remove command with the name that was used to add it.</p>
+<p><strong>cobbler distro remove --name=string</strong></p>
+<p><strong>cobbler profile remove --name=string</strong></p>
+<p><strong>cobbler system remove --name=string</strong></p>
+<p><strong>cobbler remove repo --name=string</strong></p>
+<p>
+</p>
+<h2><a name="rebuilding_configurations">REBUILDING CONFIGURATIONS</a></h2>
+<p><strong>cobbler sync</strong></p>
+<p>Cobbler sync is used to repair or rebuild the contents /tftpboot or /var/www/cobbler when something has changed behind the scenes. It brings the filesystem up to date with the configuration as understood by cobbler.</p>
+<p>Sync should be run whenever files in /var/www/cobbler are manually edited or when making changes to kickstart files. In practice, this should not happen often, though running sync too many times does not cause any adverse effects.</p>
+<p>If using cobbler to manage a DHCP server (see the advanced section of this manpage), sync does need to be
+run after systems are added to regenerate and reload the DHCP configuration.</p>
+<p>
+</p>
+<hr />
+<h1><a name="examples">EXAMPLES</a></h1>
+<p>
+</p>
+<h2><a name="import_workflow">IMPORT WORKFLOW</a></h2>
+<p>This example shows how to create a provisioning infrastructure from a distribution mirror.
+Then a default PXE configuration is created, so that by default systems will PXE boot into
+a fully automated install process for that distribution.</p>
+<p>You can use a network rsync mirror or a mounted DVD location.</p>
+<p><strong>cobbler check</strong></p>
+<p><strong>cobbler import --mirror=rsync://yourfavoritemirror.com/foo --mirror-name=anyname</strong></p>
+<p># OR</p>
+<p><strong>cobbler import --mirror=/mnt/dvd --mirror-name=anyname</strong></p>
+<p># wait for rsync to copy files...</p>
+<p><strong>cobbler report</strong></p>
+<p><strong>cobbler system add --name=default --profile=name_of_a_profile1</strong></p>
+<p><strong>cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=name_of_a_profile2</strong></p>
+<p><strong>cobbler sync</strong></p>
+<p>
+</p>
+<h2><a name="normal_workflow">NORMAL WORKFLOW</a></h2>
+<p>The following example uses a local kernel and initrd file (already downloaded), and
+shows how profiles would be created using two different kickstarts -- one for a web server
+configuration and one for a database server. Then, a machine is assigned to each profile.</p>
+<p><strong>cobbler check</strong></p>
+<p><strong>cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz --initrd=/dir1/initrd.img</strong></p>
+<p><strong>cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz --initrd=/dir2/initrd.img</strong></p>
+<p><strong>cobbler profile add --name=fc5webservers --distro=fc5-i386 --kickstart=/dir4/kick.ks --kopts=``something_to_make_my_gfx_card_work=42,some_other_parameter=foo''</strong></p>
+<p><strong>cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3 --kickstart=/dir5/kick.ks</strong></p>
+<p><strong>cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers</strong></p>
+<p><strong>cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers</strong></p>
+<p><strong>cobbler report</strong></p>
+<p>
+</p>
+<h2><a name="repository_mirroring_workflow">REPOSITORY MIRRORING WORKFLOW</a></h2>
+<p>The following example shows how to set up a repo mirror for two repositories, and create a profile
+that will auto install those repository configurations on provisioned systems using that profile.</p>
+<p><strong>cobbler check</strong></p>
+<p># set up your cobbler distros here.</p>
+<p><strong>cobbler repo add --mirror=rsync://repos.example.com/foo/i386/ --name=magicfooi386</strong></p>
+<p><strong>cobbler repo add <a href="mailto:--mirror=root at 192.168.1.5:/foo/i386/">--mirror=root at 192.168.1.5:/foo/i386/</a> --name=magicbari386</strong></p>
+<p><strong>cobbler reposync</strong></p>
+<p><strong>cobbler profile add --name=p1 --distro=existing_distro_name --kickstart=/etc/cobbler/kickstart_fc6.ks --repos=``magicfooi386 magicbari386''</strong></p>
+<p>See the expanded description towards the bottom of this manpage for further information about
+repo management.</p>
+<p>
+</p>
+<h2><a name="xen">XEN</a></h2>
+<p>For Virt, be sure the distro uses a Virt kernel and initrd and follow similar steps as above, adding additional parameters as desired:</p>
+<p><strong>cobbler distro add --name=fc5virt --kernel=/dir3/vmlinuz --initrd=/dir6/initrd.img</strong></p>
+<p>Specify reasonable values for the Virt image size (in GB) and RAM requirements:</p>
+<p><strong>cobbler profile add --name=virtwebservers --distro=fc5virt --kickstart=/dir7/kick.ks --virt-file-size=10 --virt-ram=512</strong></p>
+<p>And define systems (if desired) using MAC addresses, not IP's or hostnames:</p>
+<p><strong>cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers</strong></p>
+<p>
+</p>
+<hr />
+<h1><a name="advanced_topics">ADVANCED TOPICS</a></h1>
+<p>
+</p>
+<h2><a name="pxe_menus">PXE MENUS</a></h2>
+<p>Cobbler will automatically generate PXE menus for all profiles it has defined. Running ``cobbler sync'' is required
+to generate and update these menus.</p>
+<p>To access the menus, type ``menu'' at the ``boot:'' prompt while a system is PXE booting. If nothing is typed, the network boot
+will default to a local boot. If ``menu'' is typed, the user can then choose and provision any cobbler profile the system
+knows about.</p>
+<p>If the association between a system (MAC address) and a profile is already known, it may be more useful to just use
+``system add'' commands and declare that relationship in cobbler; however many use cases will prefer having a PXE system, especially when provisioning is done at the same time as installing new physical machines.</p>
+<p>If this behavior is not desired, run ``cobbler system add --name=default --profile=plugh'' to default all PXE booting machines to get a new copy of the profile ``plugh''. To go back to the menu system, run ``cobbler system remove --name=default'' and then ``cobbler sync'' to regenerate the menus.</p>
+<p>
+</p>
+<h2><a name="kickstart_templating">KICKSTART TEMPLATING</a></h2>
+<p>The --ksmeta options above require more explanation.</p>
+<p>If and only if --kickstart options reference filesystem URLs, --ksmeta allows for templating of the kickstart files
+to achieve advanced functions. If the --ksmeta option for a profile read --ksmeta=``foo=7 bar=llama'', anywhere
+in the kickstart file where the string ``TEMPLATE::bar'' appeared would be replaced with the string ``llama''. (Actually $bar is also replaced, if you prefer that syntax).</p>
+<p>To apply these changes, ``cobbler sync'' must be run to generate custom kickstarts for each profile/system.</p>
+<p>For NFS and HTTP URLs, the ``--ksmeta'' options will have no effect. This is a good reason to let
+cobbler manage your kickstart files, though the URL functionality is provided for integration with
+legacy infrastructure, possibly including web apps that already generate kickstarts.</p>
+<p>Templated kickstart files are processed by the templating program/package Cheetah, so anything you can do in a Cheetah template can be done to a kickstart template. Learn more at <a href="http://www.cheetahtemplate.org/learn.html">http://www.cheetahtemplate.org/learn.html</a></p>
+<p>When working with Cheetah, be sure to escape any shell macros that look like ``$(this)'' with something like ``\$(this)'' or errors may show up during the sync process.</p>
+<p>Should you want to express larger sections of templating (more that can be decently expressed on the command line), you may want to edit /var/lib/cobbler/ files directly. Keep in mind that changes need to be valid YAML 1.0 syntax and ``cobbler sync'' should be run after making any changes to those files.</p>
+<p>
+</p>
+<h2><a name="dhcp_configuration_management">DHCP CONFIGURATION MANAGEMENT</a></h2>
+<p>By default, cobbler does not write a dhcpd.conf and leaves configuration
+of DHCP up to the user. If manage_dhcp is set to 1 in /var/lib/cobbler/settings,
+this changes, and cobbler *will* write it's own dhcp.conf file, replacing any dhcpd.conf
+that already exists.</p>
+<p>The file is based on a template in /etc/cobbler/dhcpd.conf.template -- and must be user edited for
+the user's particular networking environment. Read the file and understand dhcpd.conf files before proceeding.
+If you already have dhcpd.conf data that you would like to preserve (say DHCP was manually configured earlier),
+insert the relevant portions of it into the template file.</p>
+<p>So, if this manage_dhcp bit is enabled, the following features are enabled:</p>
+<p>(A) pinning dhcp hostnames to MAC addresses automatically.
+(B) relatively seamless mixing of Itanium and x86/x86_64 machines in a PXE environment</p>
+<p>Per-system records in DHCP will only be written if the cobbler system name is a MAC address, so it's recommended that those be used if manage_dhcp is turned on.</p>
+<p>Itanium systems names also need to be specified by the MAC address, and their distribution needs to be created with the ``--arch=ia64'' parameter.</p>
+<p>The dhcpd.conf file will be updated each time ``cobbler sync'' is run, and not until then, so it is important
+to remember to use ``cobbler sync'' when using this feature.</p>
+<p>
+</p>
+<h2><a name="enchant">ENCHANT</a></h2>
+<p>While the normal provisioning procedure is either to PXE bare-metal, or use koan to do something else (kickstart an existing system or deploy Virt), cobbler contains yet another option, called ``enchant''.</p>
+<p>Enchant takes a configuration that has already been defined (be sure to run ``cobbler sync'' before using ``cobbler enchant'') and applies it to a remote system that might not have koan installed. Users might want to use this command to replace a server that is being repurposed, or when no PXE environment can be created.</p>
+<p>Essentially what enchant does is allow koan to be executed remotely from the cobbler server. Running ``enchant'' in it's normal mode will replace the operating system of the target machine, so use it with caution.</p>
+<p>Usage: <strong>cobbler enchant --address=ip|hostname --profile=string</strong>
+Usage: <strong>cobbler enchant --address=ip|hostname --system=string</strong></p>
+<p>Adding a ``--virt=yes'' to either form will provision a virtualized image rather than reprovisioning
+the remote machine. The default behavior is machine (not virtual) re-provisioning.</p>
+<p>Example: <strong>cobbler enchant --virt=yes --address=192.168.10.10 --profile=fc6xen</strong></p>
+<p>
+</p>
+<h2><a name="importing_trees">IMPORTING TREES</a></h2>
+<p>Cobbler can auto-add distributions and profiles from local or remote sources, usually an rsync mirror of the distribution or a mounted DVD. This can save a lot of time when setting up a new provisioning environment.</p>
+<p>Cobbler will try to detect the distribution type and automatically assign kickstarts. By default, it will provision the system by erasing the hard drive, setting up eth0 for dhcp, and using a default password of ``cobbler''. If this is undesirable, edit the kickstart files in /etc/cobbler to do something else or change the kickstart setting in the configuration file after cobbler finishes the import.</p>
+<p>Example: <strong>cobbler import --mirror=rsync://mirrorserver.example.com/path/ --mirror-name=fedora</strong></p>
+<p>Example: <strong>cobbler import --mirror=/mnt/dvd --mirror-name=baz</strong></p>
+<p>Once imported, run a ``cobbler list'' or ``cobbler report'' to see what you've added.</p>
+<p>By default, the rsync operations will exclude PPC content, debug RPMs, and ISO images -- to change what is excluded during an import, see /etc/cobbler/rsync.exclude.</p>
+<p>(Note: if you don't have a DVD drive, you can still download a DVD image and use ``losetup'').</p>
+<p>
+</p>
+<h2><a name="default_pxe_boot_behavior">DEFAULT PXE BOOT BEHAVIOR</a></h2>
+<p>What happens when PXE booting a system when cobbler has no record
+of the system being booted?</p>
+<p>By default, cobbler will configure PXE to boot to the contents of
+/etc/cobbler/default.pxe, which (if unmodified) will just fall through
+to the local boot process. Administrators can modify this file if they
+like to change that behavior.</p>
+<p>An easy way to specify a default cobbler profile to PXE boot is to
+create a system named ``default''. This will cause /etc/cobbler/default.pxe
+to be ignored. To restore the previous behavior do a ``cobbler system remove''
+on the ``default'' system.</p>
+<p><strong>cobbler system add --name=default --profile=boot_this</strong></p>
+<p><strong>cobbler system remove --name=default</strong></p>
+<p>
+</p>
+<h2><a name="repo_management">REPO MANAGEMENT</a></h2>
+<p>This has already been covered a good bit in the command reference section.</p>
+<p>Yum repository management is an optional feature, and is not required to provision through cobbler.
+However, if cobbler is configured to mirror certain repositories, it can then be used to associate
+profiles with those repositories. Systems installed under those profiles will then be autoconfigured
+to use these repository mirrors in /etc/yum.repos.d, and if supported (Fedora Core 6 and later) these
+repositories can be leveraged even within Anaconda. This can be useful if (A) you have a large
+install base, (B) you want fast installation and upgrades for your systems, or (C) have some
+extra software not in a standard repository but want provisioned systems to know about that repository.</p>
+<p>Make sure there is plenty of space in cobbler's webdir, which defaults to /var/www/cobbler.</p>
+<p><strong>cobbler reposync</strong></p>
+<p>Cobbler reposync is the command to use to update repos as configured with ``cobbler repo add''. Mirroring
+can take a long time, and usage of cobbler reposync prior to cobbler sync is needed to ensure
+provisioned systems have the files they need to actually use the mirrored repositories. If you just
+add repos and never run reposync, the repos will never be mirrored. This is probably a command
+you would want to put on a crontab, though the frequency of that crontab and where the output
+goes is left up to the systems administrator.</p>
+<p>Repositories that do not need to be updated can be modifed by tweaking the values in /var/lib/cobbler/repos.</p>
+<p>
+</p>
+<h2><a name="kickstart_tracking">KICKSTART TRACKING</a></h2>
+<p>Cobbler knows how to keep track of the status of kickstarting machines.</p>
+<p><strong>cobbler status</strong></p>
+<p>Using the status command will show when cobbler thinks a machine started kickstarting and when it last requested a file.
+This is a good way to track machines that may have gone interactive during kickstarts. Cobbler will also make a special
+request in the post section of the kickstart to signal when a machine is finished kickstarting.</p>
+<p>To use this feature, the kickstart tree files need to be served via a <a href="http://server/cobbler_track/...">http://server/cobbler_track/...</a> URL, which happens
+automatically when using the ``cobbler import'' command to pull in a kickstart tree from an rsync mirror.</p>
+<p>If kickstart trees are somewhere else, one can still benefit from the kickstart tracking feature by adding a symlink to
+/var/www/cobbler/localmirror/distroname will allow the kickstarts to be served through the tracking URL mentioned above. Be sure to use the <a href="http://server/cobbler_track/">http://server/cobbler_track/</a> URL to point to the kickstart tree for each distro you want to track.</p>
+<p>
+</p>
+<h2><a name="tweaking">TWEAKING</a></h2>
+<p>Enterprising users can edit the files in /var/lib/cobbler directly versus using the command line. The repair
+mechanism for user error here is to delete the files in /var/lib/cobbler. There are also a few configuration
+files in /etc/cobbler that can be edited.</p>
+<p>Running ``cobbler sync'' is required to apply any changes that are made manually.</p>
+<p>
+</p>
+<h2><a name="api">API</a></h2>
+<p>Cobbler also makes itself available as a Python API for use by higher level management software.</p>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT_STATUS</a></h1>
+<p>cobbler's command line returns a zero for success and non-zero for failure.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Michael DeHaan <<a href="mailto:mdehaan at redhat.com">mdehaan at redhat.com</a>></p>
+
+</body>
+
+</html>
diff --git a/website/cobbler.odp b/website/cobbler.odp
new file mode 100644
index 0000000..223cd04
Binary files /dev/null and b/website/cobbler.odp differ
diff --git a/website/favicon.ico b/website/favicon.ico
new file mode 100644
index 0000000..cbb6124
Binary files /dev/null and b/website/favicon.ico differ
diff --git a/website/img/black-red/callout-bg.png b/website/img/black-red/callout-bg.png
new file mode 100644
index 0000000..7d300a4
Binary files /dev/null and b/website/img/black-red/callout-bg.png differ
diff --git a/website/img/black-red/content-left-bg.png b/website/img/black-red/content-left-bg.png
new file mode 100644
index 0000000..78d9856
Binary files /dev/null and b/website/img/black-red/content-left-bg.png differ
diff --git a/website/img/black-red/content-right-bg.png b/website/img/black-red/content-right-bg.png
new file mode 100644
index 0000000..de10d7d
Binary files /dev/null and b/website/img/black-red/content-right-bg.png differ
diff --git a/website/img/black-red/hr.png b/website/img/black-red/hr.png
new file mode 100644
index 0000000..ec23c73
Binary files /dev/null and b/website/img/black-red/hr.png differ
diff --git a/website/img/black-red/topbar-bg.png b/website/img/black-red/topbar-bg.png
new file mode 100644
index 0000000..423be96
Binary files /dev/null and b/website/img/black-red/topbar-bg.png differ
diff --git a/website/img/black-red/topbar-graphic.png b/website/img/black-red/topbar-graphic.png
new file mode 100644
index 0000000..353ea02
Binary files /dev/null and b/website/img/black-red/topbar-graphic.png differ
diff --git a/website/index.html b/website/index.html
new file mode 100644
index 0000000..50109e7
--- /dev/null
+++ b/website/index.html
@@ -0,0 +1,201 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
+
+<head>
+<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
+<link rel="stylesheet" href="style.css" type="text/css" />
+<title>Cobbler -- provisioning made simple.</title>
+</head>
+<body>
+
+<div id="topbar">
+
+<div id="page-title">
+<h1 id="product-name">Cobbler
+<span id="blurb">Provisioning Made Simple</span></h1>
+</div>
+
+</div>
+
+<div class="topbar-line">
+</div>
+
+<ul class="topnav">
+<li><a href="#">About</a></li>
+<li><a href="#News">News</a></li>
+<li><a href="#Downloads">Downloads</a></li>
+<li><a href="#FAQ">FAQ</a></li>
+<li><a href="#Contact">Contact</a></li>
+</ul>
+
+<A NAME="About"></A>
+<div id="content-main">
+<h2>About</h2>
+<p>
+Cobbler is a Linux provisioning configuration tool that enables administrators to rapidly set up environments for (simultaneously) provisioning PXE, installing virtualized images, and re-provisioning existing machines. Set up of a PXE server, once a very manual process, is now greatly simplified. Cobbler also enables integrating virtualization into a PXE provisioning infrastructure and provides some interesting options to reinstall running machines as well.
+</p>
+<p>
+Cobbler is designed for managing the provisioning datacenters with 1000's of machines or labs with just a few. Extensive documentation is provided in the accompanying manpages. Cobbler is easy to use and has an accompanying Python API. The config files are also sane and XML free.
+</p>
+<p>
+Cobbler uses a helper tool called Koan to enable replacing <i>running</i> systems as well as installing virtualized profiles. Cobbler has a feature that allows pushing Koan out to systems automatically.
+</p>
+<p>
+Another interesting feature of Cobbler is that it can integrate mirroring of package repositories with the provisioning process, so that a cobbler server serves as a central mirror point of contract for all of an organization's software needs. Mirrored repositories can automatically be used by provisioned systems without additional setup. On FC6 and later, these repositories can also be used within the kickstart itself. All of this is covered in the manpage documentation.
+</p>
+
+<A NAME="News"></A>
+<h2>News</h2>
+<p>
+<B>Cobbler 0.4.5</B></br>
+Vastly improved support for importing from DVDs. <A HREF="http://et.redhat.com/page/Cobbler_Import">(examples)</A>. Shorter kernel options by default. Fully templated PXE configurations mean greater customization opportunities.
+</p>
+<p>
+<B>Cobbler 0.4.3</B></br>
+Cobbler 0.4.3 is a bugfix release. Recently 0.4.2 added auto-generated PXE menus for rapid installation of machines "just off the truck". Also, cobbler now once again uses <A HREF="http://cheetahtemplate.org/learn.html">Cheetah</A> for more-powerful kickstart templating.
+</p>
+<B>Koan 0.2.8</B><br/>
+Koan's helper program for reprovisioning and virtual installations now uses the "virtinst" library for faster, more streamlined guest provisioning.
+</p>
+
+<A NAME="Downloads"></A>
+<h2>Source/Downloads</h2>
+<p>
+Cobbler and Koan are licensed under the GPL.
+</p>
+<p>
+Source code (it's all Python) is available through <A HREF="http://git.or.cz/">git</A>. The source provided here will be somewhat more bleeding edge than the RPM's provided below, though in general source checkouts will be usable. If "stable" is desired, use the RPM releases instead.
+<ul>
+<li><A HREF="http://git.et.redhat.com/">gitweb interface</A></li>
+<li>git clone git://et.redhat.com/cobbler</li>
+<li>git clone git://et.redhat.com/koan</li>
+</ul>
+</p>
+<p>
+RPM Downloads
+<ul>
+<li>Fedora Core: "yum install cobbler", "yum install koan"
+</li>
+<li>Or: <A HREF="http://cobbler.et.redhat.com/download/">download RPMs</A>
+</li>
+<li>
+<li><A HREF="http://people.redhat.com/~dlutter/yum/rhel4/">rhel4 cobbler & koan RPMs</A></li>
+<li>Installation/Build For RHEL4:
+<ul>
+<li>wget http://www.python.org/pyvault/centos-4-i386/python-cheetah-0.9.18-1.el4.pyv.i386.rpm</li>
+<li>wget http://www.python.org/pyvault/centos-4-i386/python23-cheetah-0.9.18-1.el4.pyv.i386.rpm</li>
+<li>rpm -i python*cheetah*.rpm</li>
+<li>wget http://cobbler.et.redhat.com/download/cobbler-$version.src.rpm</li>
+<li>rpmbuild --rebuild cobbler-$version.src.rpm</i>
+<li>rpm -i /usr/src/redhat/RPMS/noarch/cobbler-$version.src.rpm</li>
+</ul>
+</li>
+</ul>
+</p>
+<p>
+Open Office Presentation
+<ul>
+<li><A HREF="http://cobbler.et.redhat.com/cobbler.odp">cobbler.odp</li></A>
+</ul>
+<p>
+User Documentation (generated from the manpages)
+<ul>
+<li><A HREF="http://cobbler.et.redhat.com/cobbler.html">cobbler</A></li>
+<li><A HREF="http://cobbler.et.redhat.com/koan.html">koan</A></li>
+</ul>
+</p>
+<p>
+Other Documentation
+<ul>
+<li><A HREF="http://et.redhat.com/page/Cobbler_Import">Tutorial on importing from a DVD</A></ul>
+</ul>
+</p>
+
+<!-- <p><a href="#">Learn more about ... now</a></p> -->
+
+<A NAME="FAQ"></A>
+<h2>FAQ</h2>
+<p>
+<B>What can Cobbler do for me?</B><br/>
+Cobbler can, if you let it, completely manage your provisioning infrastructure. It can keep your dhcpd.conf managed, it will manage your /tftpboot directory for PXE, and it will enable reprovisioning of existing hardware. It saves a systems administrator from needing to understand the differences between various provisioning types as they are all configured in a unified way. As an open source project, more importantly, technology advances can be shared -- which isn't possible with in-house developed provisioning solutions that are all-too-common in today's IT environment.
+</p>
+<p>
+<B>Who is the intended audience?</B><br/>
+Anyone, really. We want to make provisioning infrastructure just as easy to set up for someone who has a lab of 10 machines as for a corporation that has a thousand or more. Cobbler does not try to be "enterprise software". It's just software.
+</p>
+<p>
+<B>How is cobbler used?</B><br/>
+Cobbler can be used in one of three ways, currently. There's a fully featured command line application, a Python API (for advanced users), and there are cobbler's configuration files itself (also for advanced users). It's recommended that users start with the command line.
+</p>
+<p>
+<B>So no Graphical or Web User Interface?</B><br/>
+We're thinking about that.
+</p>
+<p>
+<B>How customizable is cobbler?</B><br/>
+Most features -- like dhcp.conf templating and kickstart templating -- are optional. In general, only kernel and initrd names, plus kickstart files, are required to set up a provisioning infrastructure. This makes things fairly simple. When more customization is needed, such as supporting IA64 PXE, customizing kernel parameters for a specific system, or templating kickstarts -- those features are there. The manpages do a good job of detailing optional vs. required parameters. Cobbler is essentially designed to keep provisioning easy to manage -- but to allow complicated cases to be dealt with when needed.
+</p>
+<p>
+<B>Are there any daemons involved?</B><br/>
+Cobbler configures and uses tftp-server and httpd, and (optionally) dhcpd. It configures these various apps as well as the file system tree to enable provisioning without <i>requiring</i> cobbler-specific daemons. One small syslog monitoring daemon (cobbler_syslogd) is included in 0.3.7 and later, which will enable better remote status tracking of kickstarts, though it's optional, and can be turned off with only a small degradation in kickstart tracking accuracy. If you want to remotely administer cobbler, SSH is your friend.
+</p>
+<p>
+<B>Is Cobbler tied to a particular Koan version?</B><br/>
+Not currently. Cobbler and koan tend to be very flexible. New metadata fields added to cobbler are ignored by older koan versions. Major architectural changes could affect things, though none are in plan. A best effort will be made to preserve cobbler settings across upgrades. Koan may be able to detect downlevel versions of cobbler in the future.</p>
+<p>
+<B>Does dhcpd have to run on the same box?</B><br/>
+No. In the case where you're not in control of your dhcp (which is likely), but still want a provisioning infrastructure, cobbler still works -- by default, it doesn't try to manage dhcpd.conf. Should you want to do PXE, you'll have to have your IT administrator configure DHCP a bit to add the "next-server" and "filename" records, though cobbler can point you in the right direction. Futhermore, if you're just using reprovisioning and virtualization features, then you don't need a dhcp server anyway.
+</p>
+<p>
+<B>What's the deal with the names?</B><br/>
+A cobbler is a person who makes boots. "Koan" stands for "kickstart over a network", and is kind of a play on "Xen", a Linux virtualization technology. Those responsible for naming these applications have been sacked.
+</p>
+<p>
+<B>What operating systems are supported?</B><br/>
+Cobbler and koan are intended to be used on systems that support kickstart. Cobbler currently enjoys being installed on FC-5, FC-6, RHEL-4, RHEL-5, and Centos 4 (you'll want to "rpmbuild --rebuild" the source RPM's yourself if not running Fedora). Koan (which is the helper application for non-PXE provisioning modes) works everywhere cobbler does, plus RHEL 3. Curently any Linux system can be rolled out with cobbler/koan, though there are a lot of kickstart specific features -- so distributions that do kickstart have some advantages. Patches, expertise, and suggestions on how to adapt cobbler to support other free operating systems are definitely welcome.
+</p>
+<p>
+<B>What architectures are supported?</B><br/>
+Cobbler currently can PXE-provision x86, x86_64, and (depending on how friendly your EFI is) IA64. Cobbler and koan are both noarch packages, so for provisioning modes other than PXE (such as using koan to replace a running box), there are no restrictions.
+</p>
+<p>
+<B>How can I contribute?</B><br/>
+Send in bug reports, patches, ideas, or comments. We're interested in hearing about real-world provisioning problems and how we can solve them for system administrators everywhere.
+</p>
+
+<A NAME="Contact"></A>
+<h2>Contact</h2>
+<p>Cobbler and Koan are written and maintained by <A HREF="mailto:mdehaan (AT) redhat /dot/ COM">Michael DeHaan</A>.
+</p>
+<p>
+Bug reports can be filled in <A HREF="http://bugzilla.redhat.com">Bugzilla</A> under "Fedora Extras". Both cobbler and koan have components.
+</p>
+<p>
+Send comments, questions, patches, and suggestions to the <A HREF="https://www.redhat.com/mailman/listinfo/et-mgmt-tools">et-mgmt-tools</A> list. You can send mail even if you aren't a list member. If you are on IRC, you can also stop by #cobbler on irc.freenode.net.
+</p>
+<p>
+
+<hr/>
+</div>
+
+
+<div class="content-right">
+<div class="callout-1">
+<h2>Simplicity.</h2>
+<p>
+Cobbler configures provisioning for bare metal, existing machines, and virtualization -- all at once, all in one place.
+</p>
+</div>
+
+<div class="callout-2">
+<h2>Power.</h2>
+<p>
+Advanced features include kickstart templating, dhcpd.conf generation, kernel parameter customization, kickstart tree imports, yum mirroring, kickstart status tracking, PXE menu generation, and reinstallation of remote systems. There's a lot here.
+</p>
+</div>
+</div>
+
+</body>
+</html>
diff --git a/website/koan.html b/website/koan.html
new file mode 100644
index 0000000..00fa982
--- /dev/null
+++ b/website/koan.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>NAME</title>
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body style="background-color: white">
+
+<p><a name="__index__"></a></p>
+<!-- INDEX BEGIN -->
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#notes_for_users_of_cobbler_templating">NOTES FOR USERS OF COBBLER TEMPLATING</a></li>
+ <li><a href="#additional">ADDITIONAL</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+<!-- INDEX END -->
+
+<hr />
+<p>
+</p>
+<h1><a name="name">NAME</a></h1>
+<p>koan stands for ``kickstart-over-a-network'' and allows for both
+network provisioning of new virtualized guests and destructive provisioning of
+any existing system. For use with a boot-server configured with
+'cobbler'.</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p>koan --server=<host> --list-profiles</p>
+<p>koan --server=<host> --list-systems</p>
+<p>koan --virt --server=<host> --profile=<name></p>
+<p>koan --virt --server=<host> --system=<name></p>
+<p>koan --replace-self --server=<host> --profile=<name></p>
+<p>koan --replace-self --server=<host> --system=<name></p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>When invoked, koan requests profile information from a remote boot server that has been configured with cobbler. What koan does with the profile data depends on whether it was invoked with --virt or --replace-self.</p>
+<p>For --virt, cobbler will create new virtualized guests on a machine in accordance to the orders from cobbler. You can then, once finished, use ``virsh'' and ``xm'' commands on the guest. Cobbler automatically names domains based on their mac addresses.</p>
+<p>For re-kickstarting ('--replace-self'), cobbler will reprovisioning the system, blowing away any current data and replacing it with the results of a network install.</p>
+<p>
+</p>
+<hr />
+<h1><a name="notes_for_users_of_cobbler_templating">NOTES FOR USERS OF COBBLER TEMPLATING</a></h1>
+<p>Cobbler contains an advanced templating feature that allows a single kickstart file to be customized on a per-system basis. See the cobbler manpage for more details.</p>
+<p>If you have system specific customizations in your kickstarts and have cobbler system definitions defined server side for those systems, use --system and not --profile.</p>
+<p>
+</p>
+<hr />
+<h1><a name="additional">ADDITIONAL</a></h1>
+<p>Consult the man page for cobbler for more information.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Michael DeHaan <<a href="mailto:mdehaan at redhat.com">mdehaan at redhat.com</a>></p>
+
+</body>
+
+</html>
diff --git a/website/push.sh b/website/push.sh
new file mode 100644
index 0000000..b785147
--- /dev/null
+++ b/website/push.sh
@@ -0,0 +1,6 @@
+#!/bin/sh
+scp *.html et.redhat.com:/var/www/sites/cobbler.et.redhat.com/
+scp *.odp et.redhat.com:/var/www/sites/cobbler.et.redhat.com/
+scp *.ico et.redhat.com:/var/www/sites/cobbler.et.redhat.com/
+scp *.css et.redhat.com:/var/www/sites/cobbler.et.redhat.com/
+scp -r img et.redhat.com:/var/www/sites/cobbler.et.redhat.com/
diff --git a/website/style.css b/website/style.css
new file mode 100644
index 0000000..aeeb9c9
--- /dev/null
+++ b/website/style.css
@@ -0,0 +1,152 @@
+/* These styles basically allow the top bar to be flush against the edges of the
+ browser window */
+body {
+ margin-top: 0px;
+ margin-left: 0px;
+ margin-right: 0px;
+ background: white url('img/black-red/content-right-bg.png') repeat-y right;
+}
+
+/* This is the topmost black bar on the page. It contains the name of the page
+ and some images for decoration */
+div#topbar {
+ background-color: black;
+ background-image: url('img/black-red/topbar-bg.png');
+ height: 65px;
+}
+
+/* This is just a slender red line for decorative effect. It's immediately
+ below the topmost black bar. */
+div.topbar-line {
+ background-color: maroon;
+ height: 3px;
+ color:white;
+ font-weight: bold;
+}
+
+/* This is the style that defines the bold page title in the upper left. */
+
+h1#product-name {
+ clear: left;
+ color: white;
+ padding: 0px 0px 0px 0px;
+ font-family: sans-serif;
+ margin: 0px;
+}
+
+/* This is the area where the product name & blurb are displayed */
+
+div#page-title {
+ padding-top: 23px;
+ margin: 0px;
+ height: 40px;
+ background: url('img/black-red/topbar-graphic.png') repeat-y right;
+}
+
+span#blurb {
+ margin-left: 8px;
+ padding: 0px 0px 0px 0px;
+ clear: both;
+ color: #ccc;
+ font-weight: 900;
+ font-size: large;
+ font-family: sans-serif
+}
+
+/* The follow styles are for the navigational links across the top of the page */
+ul.topnav {
+ margin: 0px;
+ padding: 0px;
+ list-style-type: none;
+ width: 100%;
+ margin-bottom: 35px;
+}
+
+ul.topnav li, ul.topnav li a, ul.topnav li a:link {
+ color: #444;
+ font-family: sans-serif;
+ font-size: medium;
+ padding: 0px 12px 4px 12px;
+ float: left;
+ text-transform: uppercase;
+ text-decoration: none;
+}
+
+ul.topnav a#selected:link{
+ background-color: #999;
+ font-weight: 900;
+ color: white;
+ padding: 2px 12px 4px 12px;
+}
+
+
+ul.topnav li a:hover {
+ background-color: #ccc;
+ color: #777;
+ font-size: medium;
+}
+
+
+div#content-main {
+ padding-left: 24px;
+ padding-right: 24px;
+ font-family: sans-serif;
+ font-size: small;
+ color: #555;
+ width: 45%;
+ float: left;
+}
+
+div#content-main h2 {
+ border-bottom: 5px solid maroon;
+ line-height: 92%;
+ padding: 0px;
+ margin-top: 15px;
+ font-size: large;
+ font-weight: 900;
+ text-transform: uppercase;
+ color: #777;
+ width: 100%;
+ text-align: right;
+}
+
+div.content-right {
+ float: right;
+ width: 25%;
+ margin-top: 30px;
+ margin-right: 12%;
+ margin-left: 12%;
+ font-family: sans-serif;
+}
+
+div.callout-1 {
+ background: maroon url('img/black-red/callout-bg.png') repeat-x center;
+ padding: 6px 12px 32px 12px;
+ margin-bottom: 32px;
+}
+
+div.callout-2 {
+ background-color: gray;
+ padding: 6px 12px 32px 12px;
+ margin-bottom: 48px;
+}
+
+div.content-right h2, div.content-right p {
+ padding: 0px;
+ margin: 0px;
+ color: white;
+}
+
+div.content-right p {
+ font-size: small;
+}
+
+div.content-right h2 {
+ font-weight: 900;
+ text-align: right;
+ font-size: x-large;
+}
+
+hr {
+ background-image: url('img/black-red/hr.png');
+}
hooks/update
---
Git Source Code Management System
hooks/update refs/heads/master \
36918f5b0cc684618e5a0e0f84f7cc380f956195 \
201120155d0a045fe1af77725c40e8f380b6182d
More information about the Et-mgmt-commits-list
mailing list