Provided by:
cobbler-common_2.2.2-0ubuntu33_all 
NAME
cobbler - a provisioning and update server
cobbler is a provisioning (installation) and update server. It
supports deployments via PXE (network booting), virtualization (Xen,
QEMU/KVM, or VMware), and re-installs of existing Linux systems. The
latter two features are enabled by usage of 'koan' on the remote
system. Update server features include yum mirroring and integration
of those mirrors with kickstart. Cobbler has a command line interface,
Web UI, and extensive Python and XMLRPC APIs for integration with
external scripts and applications.
SYNOPSIS
cobbler command [subcommand] [--arg1=value1] [--arg2=value2]
DESCRIPTION
Cobbler manages provisioning using a tiered concept of Distributions,
Profiles, Systems, and (optionally) Images and Repositories.
Distributions contain information about what kernel and initrd are
used, plus metadata (required kernel parameters, etc).
Profiles associate a Distribution with a kickstart file and optionally
customize the metadata further.
Systems associate a MAC, IP, and other networking details with a
profile and optionally customize the metadata further.
Repositories contain yum mirror information. Using cobbler to mirror
repositories is an optional feature, though provisioning and package
management share a lot in common.
Images are a catch-all concept for things that do not play nicely in
the "distribution" category. Most users will not need these records
initially and these are described later in the document.
The main advantage of cobbler is that it glues together many 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.
This manpage will focus on the cobbler command line tool for use in
configuring cobbler. There is also mention of the Cobbler WebUI which
is usable for day-to-day operation of Cobbler once
installed/configured. Docs on the API and XMLRPC components are
available online at http://fedorahosted.org/cobbler.
Most users will be interested in the Web UI and should set it up,
though the command line is needed for initial configuration -- in
particular "cobbler check" and "cobbler import", as well as the repo
mirroring features. All of these are described later in the
documentation.
SEE ALSO
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 kickstart-list@redhat.com.
Cobbler ships some kickstart templates in /etc/cobbler that may also
prove helpful.
Also see the aforementioned webpages for additional documentation, user
contributed tips, and so on.
COBBLER USAGE
SETUP
After installing, run "cobbler check" to verify that cobbler's
ecosystem is configured correctly. Cobbler check will direct you on
how to modify it's config files using a text editor.
Any problems detected should be corrected, with the potential exception
of DHCP related warnings where you will need to use your judgement as
to whether they apply to your environment. Run "cobbler sync" after
making any changes to the configuration files to ensure those changes
are applied to the environment.
It is especially important that the server name field be accurate in
/etc/cobbler/settings, without this field being correct, kickstart
trees will not be found, and automated installations will fail.
For PXE, if DHCP is to be run from the cobbler server, the dhcp
configuration file should be changed as suggested by "cobbler check".
If DHCP is not run locally, the "next-server" field on the DHCP server
should at minimum point to the cobbler server's IP and the filename
should be set to "pxelinux.0". Alternatively, cobbler can also
generate your dhcp configuration file if you want to run dhcp locally
-- this is covered in a later section. If you don't already have a
DHCP setup managed by some other tool, allowing cobbler to manage your
DHCP environment will prove to be useful as it can manage DHCP
reservations and other data. If you already have a DHCP setup, moving
an existing setup to be managed from within cobbler is relatively
painless -- though usage of the DHCP management feature is entirely
optional. If you are not interested in network booting via PXE and
just want to use koan to install virtual systems or replace existing
ones, DHCP configuration can be totally ignored. Koan also has a live
CD (see koan's manpage) capability that can be used to simulate PXE
environments.
DISTRIBUTIONS
This first step towards configurating what you want to install is to
add a distribution record to cobbler's configuration.
If there is an rsync mirror, DVD, NFS, or filesystem tree available
that you would rather import instead, skip down to the documentation
about the "import" command. It's really a lot easier to follow the
import workflow -- it only requires waiting for the mirror content to
be copied and/or scanned. Imported mirrors also save time during
install since they don't have to hit external install sources.
If you want to be explicit with distribution definition, however,
here's how it works:
cobbler distro add --name=string --kernel=path --initrd=path
[--kopts=string] [--kopts-post=string] [--ksmeta=string]
[--arch=x86|x86_64|ia64] [--breed=redhat|debian|suse]
[--template-files=string]
name
a string identifying the distribution, this should be something
like "rhel4".
kernel
An absolute filesystem path to a kernel image
initrd
An absolute filesystem path to a initrd image
kopts
Sets kernel command-line arguments that the distro, and
profiles/systems dependant on it, will use. To remove a kernel
argument that may be added by a higher cobbler object (or in the
global settings), you can prefix it with a "!".
Example: --kopts="foo=bar baz=3 asdf !gulp"
This example passes the arguments "foo=bar baz=3 asdf" but will
make sure "gulp" is not passed even if it was requested at a level
higher up in the cobbler configuration.
kopts-post
This is just like --kopts, though it governs kernel options on the
installed OS, as opposed to kernel options fed to the installer.
The syntax is exactly the same. This requires some special
snippets to be found in your kickstart template in order for this
to work. Kickstart templating is described later on in this
document.
Example: "noapic"
arch
Sets the architecture for the PXE bootloader and also controls how
koan's --replace-self option will operate.
The default setting ('standard') will use pxelinux. Set to 'ia64'
to use elilo. 'ppc' and 'ppc64' use yaboot. 's390x' is not
PXEable, but koan supports it for reinstalls.
'x86' and 'x86_64' effectively do the same thing as standard.
If you perform a cobbler import, the arch field will be auto-
assigned.
ksmeta
This is an advanced feature that sets kickstart variables to
substitute, thus enabling kickstart files to be treated as
templates. Templates are powered using Cheetah and are described
further along in this manpage as well as on the Cobbler Wiki.
Example: --ksmeta="foo=bar baz=3 asdf"
See the section on "Kickstart Templating" for further information.
breed
Controls how various physical and virtual parameters, including
kernel arguments for automatic installation, are to be treated.
Defaults to "redhat", which is a suitable value for Fedora and
CentOS as well. It means anything redhat based.
There is limited experimental support for specifying "debian",
"ubuntu", or "suse", which treats the kickstart file as a different
format and changes the kernel arguments appropriately. Support
for other types of distributions is possible in the future. See
the Wiki for the latest information about support for these
distributions.
The file used for the answer file, regardless of the breed setting,
is the value used for --kickstart when creating the profile. In
other words, if another distro calls their answer file something
other than a "kickstart", the kickstart parameter still governs
where that answer file is.
os-version
Generally this field can be ignored. It is intended to alter some
hardware setup for virtualized instances when provisioning guests
with koan. The valid options for --os-version vary depending on
what is specified for --breed. If you specify an invalid option,
the error message will contain a list of valid os versions that can
be used. If you do not know the os version or it does not appear
in the list, omitting this argument or using "other" should be
perfectly fine. Largely this is needed to support older
distributions in virtualized settings, such as "rhel2.1", one of
the OS choices if the breed is set to "redhat". If you do not
encounter any problems with virtualized instances, this option can
be safely ignored.
owners
Users with small sites and a limited number of admins can probably
ignore this option. All cobbler objects (distros, profiles,
systems, and repos) can take a --owners parameter to specify what
cobbler users can edit particular objects. This only applies to
the Cobbler WebUI and XMLRPC interface, not the "cobbler" command
line tool run from the shell. Furthermore, this is only respected
by the "authz_ownership" module which must be enabled in
/etc/cobbler/modules.conf. The value for --owners is a space
seperated list of users and groups as specified in
/etc/cobbler/users.conf. For more information see the users.conf
file as well as the Cobbler Wiki. In the default Cobbler
configuration, this value is completely ignored, as is users.conf.
template-files
This feature allows cobbler to be used as a configuration
management system. The argument is a space delimited string of
key=value pairs. Each key is the path to a template file, each
value is the path to install the file on the system. This is
described in further detail on the Cobbler Wiki and is implemented
using special code in the post install. Koan also can retrieve
these files from a cobbler server on demand, effectively allowing
cobbler to function as a lightweight templated configuration
management system.
redhat-management-key
If you're using Red Hat Network, Red Hat Satellite Server, or
Spacewalk, you can store your authentication keys here and Cobbler
can add the neccessary authentication code to your kickstart where
the snippet named "redhat_register" is included. Read more about
setup in /etc/cobbler/settings.
PROFILES
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. In this way, profiles define a role
to be performed.
cobbler profile add --name=string --distro=string [--kickstart=path]
[--kopts=string] [--ksmeta=string] [--virt-file-size=gigabytes]
[--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer]
[--virt-path=string] [--virt-bridge=string] [--server-override]
[--parent=profile]
Arguments are the same as listed for distributions, save for the
removal of "arch" and "breed", and with the additions listed below:
name
A descriptive name. This could be something like "rhel5webservers"
or "f9desktops".
distro
The name of a previously defined cobbler distribution. This value
is required.
kickstart
Local filesystem path to a kickstart file. http:// URLs (even
CGI's) are also accepted, but a local file path is recommended, so
that the kickstart templating engine can be taken advantage of.
If this parameter is not provided, the kickstart file will default
to /var/lib/cobbler/kickstarts/default.ks. This file is initially
blank, meaning default kickstarts are not automated "out of the
box". Admins can change the default.ks if they desire.
When using kickstart files, they can be placed anywhere on the
filesystem, but the recommended path is
/var/lib/cobbler/kickstarts. If using the webapp to create new
kickstarts, this is where the web application will put them.
nameservers
If your nameservers are not provided by DHCP, you can specify a
space seperated list of addresses here to configure each of the
installed nodes to use them (provided the kickstarts used are
installed on a per-system basis). Users with DHCP setups should
not need to use this option. This is available to set in profiles
to avoid having to set it repeatedly for each system record.
virt-file-size
(Virt-only) How large the disk image should be in Gigabytes. The
default is "5". This can be a space seperated list (ex: "5,6,7")
to allow for multiple disks of different sizes depending on what is
given to --virt-path. This should be input as a integer or decimal
value without units.
virt-ram
(Virt-only) How many megabytes of RAM to consume. The default is
512 MB. This should be input as an integer without units.
virt-type
(Virt-only) Koan can install images using either Xen paravirt
("xenpv") or QEMU/KVM ("qemu"). Choose one or the other strings to
specify, or values will default to attempting to find a compatible
installation type on the client system ("auto"). See the "koan"
manpage for more documentation. The default virt-type can be
configured in the cobbler settings file such that this parameter
does not have to be provided. Other virtualization types are
supported, for information on those options (such as VMware), see
the Cobbler Wiki.
virt-cpus
(Virt-only) How many virtual CPUs should koan give the virtual
machine? The default is 1. This is an integer.
virt-path
(Virt-only) Where to store the virtual image on the host system.
Except for advanced cases, this parameter can usually be omitted.
For disk images, the value is usually an absolute path to an
existing directory with an optional file name component. There is
support for specifying partitions "/dev/sda4" or volume groups
"VolGroup00", etc.
For multiple disks, seperate the values with commas such as
"VolGroup00,VolGroup00" or "/dev/sda4,/dev/sda5". Both those
examples would create two disks for the VM.
virt-bridge
(Virt-only) This specifies the default bridge to use for all
systems defined under this profile. If not specified, it will
assume the default value in the cobbler settings file, which as
shipped in the RPM is 'xenbr0'. If using KVM, this is most likely
not correct. You may want to override this setting in the system
object. Bridge settings are important as they define how outside
networking will reach the guest. For more information on bridge
setup, see the Cobbler Wiki, where there is a section describing
koan usage.
repos
This is a space delimited list of all the repos (created with
"cobbler repo add" and updated with "cobbler reposync") that this
profile can make use of during kickstart installation. For
example, an example might be --repos="fc6i386updates fc6i386extras"
if the profile wants to access these two mirrors that are already
mirrored on the cobbler server. Repo management is described in
greater depth later in the manpage.
parent
This is an advanced feature.
Profiles may inherit from other profiles in lieu of specifing
--distro. Inherited profiles will override any settings specified
in their parent, with the exception of --ksmeta (templating) and
--kopts (kernel options), which will be blended together.
Example: If profile A has --kopts="x=7 y=2", B inherits from A,
and B has --kopts="x=9 z=2", the actual kernel options that will be
used for B are "x=9 y=2 z=2".
Example: If profile B has --virt-ram=256 and A has --virt-ram of
512, profile B will use the value 256. Example: If profile A has
a --virt-file-size of 5 and B does not specify a size, B will use
the value from A.
server-override
This parameter should be useful only in select circumstances. If
machines are on a subnet that cannot access the cobbler server
using the name/IP as configured in the cobbler settings file, use
this parameter to override that server name. See also --dhcp-tag
for configuring the next server and DHCP informmation of the system
if you are also using Cobbler to help manage your DHCP
configuration.
SYSTEMS
System records map a piece of hardware (or a virtual machine) with the
cobbler profile to be assigned to run on it. This may be thought of as
chosing a role for a specific system.
Note that if provisioning via koan and PXE menus alone, it is not
required to create system records in cobbler, though they are useful
when system specific customizations are required. One such
customization would be defining the MAC address. If there is a
specific role inteded for a given machine, system records should be
created for it.
System commands have a wider variety of control offered over network
details. In order to use these to the fullest possible extent, the
kickstart template used by cobbler must contain certain kickstart
snippets (sections of code specifically written for Cobbler to make
these values become reality). Compare your kickstart templates with
the stock ones in /var/lib/cobbler/kickstarts if you have upgraded, to
make sure you can take advantage of all options to their fullest
potential. If you are a new cobbler user, base your kickstarts off of
these templates. Non-kickstart based distributions, while supported by
Cobbler, may not be able to use all of these features.
Read more about networking setup at:
https://fedorahosted.org/cobbler/wiki/AdvancedNetworking
cobbler system add --name=string --profile=string [--mac=macaddress]
[--ip=ipaddress] [--hostname=hostname] [--kopts=string]
[--ksmeta=string] [--kickstart=path] [--netboot-enabled=Y/N]
[--server-override=string] [--gateway=string] [--dns-name=string]
[--static-routes=string] [--power-address=string] [--power-type=string]
[--power-user=string] [--power-password=string] [--power-id=string]
Adds a cobbler System to the configuration. Arguments are specified as
per "profile add" with the following changes:
name
The system name works like the name option for other commands.
If the name looks like a MAC address or an IP, the name will
implicitly be used for either --mac or --ip of the first interface,
respectively. However, it's usually better to give a descriptive
name -- don't rely on this behavior.
A system created with name "default" has special semantics. If a
default system object exists, it sets all undefined systems to PXE
to a specific profile. Without a "default" system name created,
PXE will fall through to local boot for unconfigured systems.
When using "default" name, don't specify any other arguments than
--profile ... they won't be used.
--mac
Specifying a mac address via --mac allows the system object to boot
directly to a specific profile via PXE, bypassing cobbler's PXE
menu. If the name of the cobbler system already looks like a mac
address, this is inferred from the system name and does not need to
be specified.
MAC addresses have the format AA:BB:CC:DD:EE:FF. It's higly
recommended to register your MAC-addresses in Cobbler if you're
using static adressing with multiple interfaces, or if you are
using any of the advanced networking features like bonding, bridges
or VLANs.
Cobbler does contain a feature (enabled in /etc/cobbler/settings)
that can automatically add new system records when it finds
profiles being provisioned on hardware it has seen before. This
may help if you do not have a report of all the MAC addresses in
your datacenter/lab configuration.
--ip
If cobbler is configured to generate a DHCP configuratition (see
advanced section), use this setting to define a specific IP for
this system in DHCP. Leaving off this parameter will result in no
DHCP management for this particular system.
Example: --ip=192.168.1.50
Note for Itanium users: this setting is always required for IA64
regardless of whether DHCP management is enabled.
If DHCP management is disabled and the interface is labelled
--static=1, this setting will be used for static IP configuration.
Special feature: To control the default PXE behavior for an entire
subnet, this field can also be passed in using CIDR notation. If
--ip is CIDR, do not specify any other arguments other than --name
and --profile.
When using the CIDR notation trick, don't specify any arguments
other than --name and --profile... they won't be used.
--dns-name
If using the DNS management feature (see advanced section --
cobbler supports auto-setup of BIND and dnsmasq), use this to
define a hostname for the system to receive from DNS.
Example: --dns-name=mycomputer.example.com
This is a per-interface parameter. If you have multiple
interfaces, it may be different for each interface, for example,
assume a DMZ / dual-homed setup.
--gateway and --subnet
If you are using static IP configurations and the interface is
flagged --static=1, these will be applied.
Subnet is a per-interface parameter. Because of the way gateway is
stored on the installed OS, gateway is a global parameter. You may
usse --static-routes for per-interface customizations if required.
--hostname
This field corresponds to the hostname set in a systems
/etc/sysconfig/network file. This has no bearing on DNS, even when
manage_dns is enabled. Use --dns-name instead for that feature.
This parameter is assigned once per system, it is not a per-
interface setting.
--power-address, --power-type, --power-user, --power-password,
--power-id
Cobbler contains features that enable integration with power
management for easier installation, reinstallation, and management
of machines in a datacenter environment. These parameters are
described online at
https://fedorahosted.org/cobbler/wiki/PowerManagement. If you have
a power-managed datacenter/lab setup, usage of these features may
be something you are interested in.
--static
Indicates that this interface is statically configured. Many
fields (such as gateway/subnet) will not be used unless this field
is enabled.
This is a per-interface setting.
--static-routes
This is a space delimited list of ip/mask:gateway routing
information in that format. Most systems will not need this
information.
This is a per-interface setting.
--virt-bridge
(Virt-only) While --virt-bridge is present in the profile object
(see above), here it works on an interface by interface basis.
For instance it would be possible to have --virt-bridge0=xenbr0 and
--virt-bridge1=xenbr1. If not specified in cobbler for each
interface, koan will use the value as specified in the profile for
each interface, which may not always be what is intended, but will
be sufficient in most cases.
This is a per-interface setting.
--kickstart
While it is recommended that the --kickstart parameter is only used
within for the "profile add" command, there are limited scenarios
when an install base switching to cobbler may have legacy
kickstarts created on a per-system basis (one kickstart for each
system, nothing shared) and may not want to immediately make use of
the cobbler templating system. This allows specifing a kickstart
for use on a per-system basis. Creation of a parent profile is
still required. If the kickstart is a filesystem location, it will
still be treated as a cobbler template.
--netboot-enabled
If set false, the system will be provisionable through koan but not
through standard PXE. This will allow the system to fall back to
default PXE boot behavior without deleting the cobbler system
object. The default value allows PXE. Cobbler contains a PXE
boot loop prevention feature (pxe_just_once, can be enabled in
/etc/cobbler/settings) that can automatically trip off this value
after a system gets done installing. This can prevent installs
from appearing in an endless loop when the system is set to PXE
first in the BIOS order.
--ldap-enabled, --ldap-type
Cobbler contains features that enable ldap management for easier
configuration after system provisioning. If set true, koan will run
the ldap command as defined by the systems ldap_type. The default
value is false.
--monit-enabled
If set true, koan will reload monit after each configuration run.
The default value is false.
--repos-enabled
If set true, koan can reconfigure repositories after installation.
This is described further on the Cobbler Wiki,
https://fedorahosted.org/cobbler/wiki/ManageYumRepos.
--dhcp-tag
If you are setting up a PXE environment with multiple
subnets/gateways, and are using cobbler to manage a DHCP
configuration, you will probably want to use this option. If not,
it canbe ignored.
By default, the dhcp tag for all systems is "default" and means
that in the DHCP template files the systems will expand out where
$insert_cobbler_systems_definitions is found in the DHCP template.
However, you may want certain systems to expand out in other places
in the DHCP config file. Setting --dhcp-tag=subnet2 for instance,
will cause that system to expand out where
$insert_cobbler_system_definitions_subnet2 is found, allowing you
to insert directives to specify different subnets (or other
parameters) before the DHCP configuration entries for those
particular systems.
This is described further on the Cobbler Wiki.
--interface
By default flags like --ip, --mac, --dhcp-tag, --dns-name,
--subnet, --virt-bridge, and --static-routes operate on the first
network interface defined for a system (eth0). However, cobbler
supports an arbitrary number of interfaces. Using --interface=eth1
for instance, will allow creating and editing of a second
interface.
Interface naming notes:
Additional interfaces can be specified (for example: eth1, or any
name you like, as long as it does not conflict with any reserved
names such as kernel module names) for use with the edit command.
Defining VLANs this way is also supported, of you want to add VLAN
5 on interface eth0, simply name your interface eth0:5.
Example:
cobbler system edit --name=foo --ip=192.168.1.50
--mac=AA:BB:CC:DD:EE:A0 cobbler system edit --name=foo
--interface=eth0 --ip=192.168.1.51 --mac=AA:BB:CC:DD:EE:A1 cobbler
system report foo
Interfaces can be deleted using the --delete-interface option.
Example:
cobbler system edit --name=foo --interface=eth2 --delete-interface
--interface-type, --interface-master and --bonding-opts/--bridge-opts
One of the other advanced networking features supported by Cobbler
is NIC bonding and bridging. You can use this to bond multiple
physical network interfaces to one single logical interface to
reduce single points of failure in your network, or to create
bridged interfaces for things like tunnels and virtual machine
networks. Supported values for the --interface-type parameter are
"bond", "bond_slave", "bridge" and "bridge_slave". If one of the
"_slave" options is specified, you also need to define the master-
interface for this bond using --interface-master=INTERFACE. Bonding
and bridge options for the master-interface may be specified using
--bonding-opts="foo=1 bar=2" or --bridge-opts="foo=1 bar=2",
respectively.
Note: The options "master" and "slave" are deprecated, and are
assumed to me "bond" and "bond_slave" when encountered. When a
system object is saved, the deprecated values will be overwritten
with the new, correct values.
Example:
cobbler system edit --name=foo --interface=eth0
--mac=AA:BB:CC:DD:EE:00 --interface-type=bond_slave
--interface-master=bond0 cobbler system edit --name=foo
--interface=eth1 --mac=AA:BB:CC:DD:EE:01
--interface-type=bond_slave --interface-master=bond0 cobbler system
edit --name=foo --interface=bond0 --interface-type=bond
--bonding-opts="mode=active-backup miimon=100" --ip=192.168.0.63
--subnet=255.255.255.0 --gateway=192.168.0.1 --static=1
More information about networking setup is available at
https://fedorahosted.org/cobbler/wiki/AdvancedNetworking
To review what networking configuration you have for any object,
run "cobbler system report" at any time:
Example:
cobbler system report --name=foo
REPOSITORIES
Repository mirroring allows cobbler to mirror not only install trees
("cobbler import" does this for you) but also optional packages, 3rd
party content, and even updates. Mirroring all of this content
locally on your network will result in faster, more up-to-date
installations and faster updates. If you are only provisioning a home
setup, this will probably be overkill, though it can be very useful for
larger setups (labs, datacenters, etc).
cobbler repo add --mirror=url --name=string [--rpmlist=list]
[--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number]
[--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn]
mirror
The addresss of the yum mirror. This can be an rsync:// URL, an
ssh location, or a http:// or ftp:// mirror location. Filesystem
paths also work.
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.
Here's an example of what looks like a good URL:
rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386
(for rsync protocol)
http://mirrors.kernel.org/fedora/extras/6/i386/ (for http://)
user@yourmirror.example.com/fedora-linux-core/updates/6/i386 (for
SSH)
Experimental support is also provided for mirroring RHN content
when you need a fast local mirror. The mirror syntax for this is
--mirror=rhn://channel-name and you must have entitlements for this
to work. This requires the cobbler server to be installed on RHEL5
or later. You will also need a version of yum-utils equal or
greater to 1.0.4.
name
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". Again, be specific.
This name corresponds with values given to the --repos parameter of
"cobbler profile add". If a profile has a --repos value that
matches the name given here, that repo can be automatically set up
during provisioning (when supported) and installed systems will
also use the boot server as a mirror (unless
"yum_post_install_mirror" is disabled in the settings file). By
default the provisioning server will act as a mirror to systems it
installs, which may not be desirable for laptop configurations,
etc.
Distros that can make use of yum repositories during kickstart
include FC6 and later, RHEL 5 and later, and derivative
distributions.
See the documentation on "cobbler profile add" for more
information.
rpm-list
By specifying a space-delimited list of package names for
--rpm-list, one can decide to mirror only a part of a repo (the
list of packages given, plus dependencies). This may be helpful in
conserving time/space/bandwidth. For instance, when mirroring FC6
Extras, it may be desired to mirror just cobbler and koan, and skip
all of the game packages. To do this, use --rpm-list="cobbler
koan".
This option only works for http:// and ftp:// repositories (as it
is powered by yumdownloader). It will be ignored for other mirror
types, such as local paths and rsync:// mirrors.
createrepo-flags
Specifies optional flags to feed into the createrepo tool, which is
called when "cobbler reposync" is run for the given repository.
The defaults are '-c cache'.
keep-updated
Specifies that the named repository should not be updated during a
normal "cobbler reposync". The repo may still be updated by
name. The repo should be synced at least once before disabling
this feature See "cobbler reposync" below.
mirror-locally
When set to "N", specifies that this yum repo is to be referenced
directly via kickstarts and not mirrored locally on the cobbler
server. Only http:// and ftp:// mirror urls are supported when
using --mirror-locally=N, you cannot use filesystem URLs.
priority
Specifies the priority of the repository (the lower the number, the
higher the priority), which applies to installed machines using the
repositories that also have the yum priorities plugin installed.
The default priority for the plugin is 99, as is that of all
cobbler mirrored repositories.
arch
Specifies what architecture the repository should use. By default
the current system arch (of the server) is used, which may not be
desirable. Using this to override the default arch allows
mirroring of source repositories (using --arch=src).
yumopts
Sets values for additional yum options that the repo should use on
installed systems. For instance if a yum plugin takes a certain
parameter "alpha" and "beta", use something like --yumopts="alpha=2
beta=3".
breed
Ordinarily cobbler's repo system will understand what you mean
without supplying this parameter, though you can set it explicitly
if needed.
MANAGEMENT CLASSES
Management classes allows cobbler to function as an configuration
management system. Cobbler currently supports the following resource
types:
1. Packages
2. Files
Resources are executed in the order listed above.
cobbler mgmtclass add --name=string --comment=string [--packages=list]
[--files=list]
name
The name of the mgmtclass. Use this name when adding a management
class to a system, profile, or distro. To add a mgmtclass to an
existing system use something like (cobbler system edit
--name="madhatter" --mgmt-classes="http mysql").
comment
A comment that describes the functions of the management class.
packages
Specifies a list of package resources required by the management
class.
files
Specifies a list of file resources required by the management
class.
MANAGEMENT RESOURCES
Resources are the lego blocks of configuration management. Resources
are grouped together via Management Classes, which are then linked to a
system. Cobbler supports two (2) resource types. Resources are
configured in the order listed below.
1. Packages
2. Files
PACKAGE RESOURCES
Package resources are managed using cobbler package add
Actions
install
Install the package. [Default]
uninstall
Uninstall the package.
Attributes
installer
Which package manager to use, vaild options [rpm|yum].
version
Which version of the package to install.
Examples
cobbler package add --name=string --comment=string
[--action=install|uninstall] --installer=string [--version=string]
FILE RESOURCES
Actions
create
Create the file. [Default]
remove
Remove the file.
Attributes
mode
Permission mode (as in chmod).
group
The group owner of the file.
user
The user for the file.
path
The path for the file.
template
The template for the file.
Examples
cobbler file add --name=string --comment=string [--action=string]
--mode=string --group=string --user=string --path=string
[--template=string]
DISPLAYING CONFIGURATION ENTRIES
The following commands are usable regardless of how you are using
cobbler. "report" gives detailed configuration info. "list" just lists
the names of items in the configuration. Run these commands to check
how you have cobbler configured.
cobbler list
cobbler distro|profile|system|repo|image|mgmtclass|package|file list
cobbler report
cobbler distro|profile|system|repo|image|mgmtclass|package|file report
--name=[object-name]
Alternatively, you could look at the configuration files in
/var/lib/cobbler to see the same information.
DELETING CONFIGURATION ENTRIES
If you want to remove a specific object, use the remove command with
the name that was used to add it.
cobbler distro remove --name=string
cobbler profile remove --name=string
cobbler system remove --name=string
cobbler repo remove --name=string
cobbler image remove --name=string
cobbler mgmtclass remove --name=string
cobbler package remove --name=string
cobbler file remove --name=string
EDITING
If you want to change a particular setting without doing an "add"
again, use the "edit" command, using the same name you gave when you
added the item. Anything supplied in the parameter list will overwrite
the settings in the existing object, preserving settings not mentioned.
cobbler distro|profile|system|repo|image|mgmtclass|package|file edit
--name=string [parameterlist]
COPYING
Objects can also be copied:
cobbler distro|profile|system|repo|image|mgmtclass|package|file copy
--name=oldname --newname=newname
RENAMING
Objects can also be renamed, as long as other objects don't reference
them.
cobbler distro|profile|system|repo|image|mgmtclass|package|file rename
--name=oldname --newname=newname
REPLICATING
Cobbler can replicate configurations from a master cobbler server.
Each cobbler server is still expected to have a locally relevant
/etc/cobbler/cobbler.conf and modules.conf, as these files are not
synced.
This feature is intended for load-balancing, disaster-recovery, backup,
or multiple geography support.
cobbler replicate --master=cobbler.example.org [--distros=pattern]
[--profiles=pattern] [--systems=pattern] [--repos-pattern]
[--images=pattern] [--prune] [--omit-data]
Cobbler can replicate data from a central server.
Objects that need to be replicated should be specified with a pattern,
such as --profiles="webservers* dbservers*" or
--systems="*.example.org". All objects matched by the pattern, and
all dependencies of those objects matched by the pattern (recursively)
will be transferred from the remote server to the central server. This
is to say if you intend to transfer "*.example.org" and the definition
of the systems have not changed, but a profile above them has changed,
the changes to that profile will also be transferred.
In the case where objects are more recent on the local server, those
changes will not be overridden locally.
Common data locations will be rsync'ed from the master server unless
--omit-data is specified.
To delete objects that are no longer present on the master server, use
--prune. Warning: this will delete all object types not present on
the remote server from the local server, and is recursive. If you use
prune, it is best to manage cobbler centrally and not expect changes
made on the slave servers to be preserved. It is not currently
possible to just prune objects of a specific type.
REBUILDING CONFIGURATIONS
cobbler sync
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.
Sync should be run whenever files in /var/lib/cobbler are manually
edited (which is not recommended except for the settings file) 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.
If using cobbler to manage a DHCP and/or DNS server (see the advanced
section of this manpage), sync does need to be run after systems are
added to regenerate and reload the DHCP/DNS configurations.
The sync process can also be kicked off from the web interface.
EXAMPLES
IMPORT WORKFLOW
Import is a very useful command that makes starting out with cobbler
very quick and easy.
This example shows how to create a provisioning infrastructure from a
distribution mirror or DVD ISO. Then a default PXE configuration is
created, so that by default systems will PXE boot into a fully
automated install process for that distribution.
You can use a network rsync mirror, a mounted DVD location, or a tree
you have available via a network filesystem.
Import knows how to autodetect the architecture of what is being
imported, though to make sure things are named correctly, it's always a
good idea to specify --arch. For instance, if you import a
distribution named "fedora8" from an ISO, and it's an x86_64 ISO,
specify --arch=x86_64 and the distro will be named "fedora8-x86_64"
automatically, and the right architecture field will also be set on the
distribution object. If you are batch importing an entire mirror
(containing multiple distributions and arches), you don't have to do
this, as cobbler will set the names for things based on the paths it
finds.
cobbler check
cobbler import --path=rsync://yourfavoritemirror.com/foo --name=rhel5
--arch=x86
# OR
cobbler import --path=/mnt/dvd --name=rhel5 --arch=x86_64
# OR (using an eternal NAS box without mirroring)
cobbler import --path=/path/where/filer/is/mounted --name=anyname
--available-as=nfs://nfs.example.org:/where/mounted/
# wait for mirror to rsync...
cobbler report
cobbler system add --name=default --profile=name_of_a_profile1
cobbler system add --name=AA:BB:CC:DD:EE:FF
--profile=name_of_a_profile2
cobbler sync
NON-IMPORT (MANUAL) WORKFLOW
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.
cobbler check
cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz
--initrd=/dir1/initrd.img
cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz
--initrd=/dir2/initrd.img
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"
cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3
--kickstart=/dir5/kick.ks
cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
cobbler report
REPOSITORY MIRRORING WORKFLOW
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.
cobbler check
# set up your cobbler distros here.
cobbler repo add
--mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/
--name=fc6i386updates
cobbler repo add
--mirror=http://mirrors.kernel.org/fedora/extras/6/i386/
--name=fc6i386extras
cobbler reposync
cobbler profile add --name=p1 --distro=existing_distro_name
--kickstart=/etc/cobbler/kickstart_fc6.ks --repos="fc6i386updates
fc6i386extras"
VIRTUALIZATION
For Virt, be sure the distro uses the correct kernel (if paravirt) and
follow similar steps as above, adding additional parameters as desired:
cobbler distro add --name=fc7virt [options...]
Specify reasonable values for the Virt image size (in GB) and RAM
requirements (in MB):
cobbler profile add --name=virtwebservers --distro=fc7virt
--kickstart=path --virt-file-size=10 --virt-ram=512 [...]
Define systems if desired. koan can also provision based on the
profile name.
cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers
[...]
If you have just installed cobbler, be sure that the "cobblerd" service
is running and that port 25151 is unblocked.
See the manpage for koan for the client side steps.
ADVANCED TOPICS
PXE MENUS
Cobbler will automatically generate PXE menus for all profiles it has
defined. Running "cobbler sync" is required to generate and update
these menus.
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.
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.
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.
When using PXE menu deployment exclusively, it is not neccessary to
make cobbler system records, although the two can easily be mixed.
Additionally, note that all files generated for the pxe menu
configurations are templatable, so if you wish to change the color
scheme or equivalent, see the files in /etc/cobbler.
KICKSTART TEMPLATING
The --ksmeta options above require more explanation.
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 "$bar"
appeared would be replaced with the string "llama".
To apply these changes, "cobbler sync" must be run to generate custom
kickstarts for each profile/system.
For NFS and HTTP kickstart 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.
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
http://www.cheetahtemplate.org/learn.html
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.
The Cobbler Wiki also contains numerous Cheetah examples that should
prove useful in using this feature.
KICKSTART SNIPPETS
Anywhere a kickstart template mentions SNIPPET::snippet_name, the file
named /var/lib/cobbler/snippets/snippet_name (if present) will be
included automatically in the kickstart template. This serves as a way
to recycle frequently used kickstart snippets without duplication.
Snippets can contain templating variables, and the variables will be
evaluated according to the profile and/or system as one would expect.
Snippets can also be overridden for specific profile names or system
names. This is described on the Cobbler Wiki.
KICKSTART VALIDATION
To check for potential errors in kickstarts, prior to installation, use
"cobbler validateks". This function will check all profile and system
kickstarts for detectable errors. Since pykickstart is not future-
Anaconda-version aware, there may be some false positives. It should
be noted that "cobbler validateks" runs on the rendered kickstart
output, not kickstart templates themselves.
DHCP MANAGEMENT
Cobbler can optionally help you manage DHCP server. This feature is
off by default.
Choose either "management = isc_and_bind" in /etc/cobbler/dhcp.template
or "management = "dnsmasq" in /etc/cobbler/modules.conf. Then set
"manage_dhcp" to 1 in /etc/cobbler/settings.
This allows DHCP to be managed via "cobbler system add" commands, when
you specify the mac address and IP address for systems you add into
cobbler.
Depending on your choice, cobbler will use /etc/cobbler/dhcpd.template
or /etc/cobbler/dnsmasq.template as a starting point. This file must
be user edited for the user's particular networking environment. Read
the file and understand how the particular app (ISC dhcpd or dnsmasq)
work before proceeding.
If you already have DHCP configuration data that you would like to
preserve (say DHCP was manually configured earlier), insert the
relevant portions of it into the template file, as running "cobbler
sync" will overwrite your previous configuration.
NOTE: Itanium systems names also need to be assigned to a distro that
was created with the "--arch=ia64" parameter. If you have Itanium
systems, you must (for now) choose 'dhcp_isc' for
/etc/cobbler/modules.conf and manage_dhcp in the /etc/cobbler/settings
file, and are required to use --ip when creating the system object in
order for those systems to PXE. This is due to an elilo limitation.
By default, the DHCP configuration 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.
If omapi_enabled is set to 1 in /etc/cobbler/settings, the need to sync
when adding new system records can be eliminated. However, the omapi
feature is experimental and is not recommended for most users.
DNS CONFIGURATION MANAGEMENT
Cobbler can optionally manage DNS configuration using BIND and dnsmasq.
Choose either "management = isc_and_bind" or "management = dnsmasq" in
/etc/cobbler/modules.conf and then enable manage_dns in
/etc/cobbler/settings.
This feature is off by default. If using BIND, you must define the
zones to be managed with the options 'manage_forward_zones' and
'manage_reverse_zones'. (See the Wiki for more information on this).
If using BIND, Cobbler will use /etc/cobbler/bind.template and
/etc/cobbler/zone.template as a starting point for the named.conf and
individual zone files, respectively. You may drop zone-specific
template files in /etc/cobbler/zone_templates/name-of-zone which will
override the default. These files must be user edited for the user's
particular networking environment. Read the file and understand how
BIND works before proceeding.
If using dnsmasq, the template is /etc/cobbler/dnsmasq.template. Read
this file and understand how dnsmasq works before proceeding.
All managed files (whether zone files and named.conf for BIND, or
dnsmasq.conf for dnsmasq) 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.
SERVICE DISCOVERY (AVAHI)
If the avahi-tools package is installed, cobblerd will broadcast it's
presence on the network, allowing it to be discovered by koan with the
koan --server=DISCOVER parameter.
IMPORTING TREES
Cobbler can auto-add distributions and profiles from remote sources,
whether this is a filesystem path or an rsync mirror. This can save a
lot of time when setting up a new provisioning environment. Import is
a feature that many users will want to take advantage of, and is very
simple to use.
After an import is run, 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 after cobbler creates the profile.
Mirrored content is saved automatically in /var/www/cobbler/ks_mirror.
Example: cobbler import --path=rsync://mirrorserver.example.com/path/
--name=fedora --arch=x86
Example2: cobbler import --path=root@192.168.1.10:/stuff --name=bar
Example3: cobbler import --path=/mnt/dvd --name=baz --arch=x86_64
Example4: cobbler import --path=/path/to/stuff --name=glorp
Example5: cobbler import --path=/path/where/filer/is/mounted
--name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
Once imported, run a "cobbler list" or "cobbler report" to see what
you've added.
By default, the rsync operations will exclude content of certain
architectures, debug RPMs, and ISO images -- to change what is excluded
during an import, see /etc/cobbler/rsync.exclude.
Note that all of the import commands will mirror install tree content
into /var/www/cobbler unless a network accessible location is given
with --available-as. --available-as will be primarily used when
importing distros stored on an external NAS box, or potentially on
another partition on the same machine that is already accessible via
http:// or ftp://.
For import methods using rsync, additional flags can be passed to rsync
with the option --rsync-flags.
Should you want to force the usage of a specific cobbler kickstart
template for all profiles created by an import, you can feed the option
--kickstart to import, to bypass the built-in kickstart auto-detection.
DEFAULT PXE BOOT BEHAVIOR
What happens when PXE booting a system when cobbler has no record of
the system being booted?
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.
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.
cobbler system add --name=default --profile=boot_this
cobbler system remove --name=default
As mentioned in earlier sections, it is also possible to control the
default behavior for a specific network:
cobbler system add --name=network1 --ip=192.168.0.0/24
--profile=boot_this
REPO MANAGEMENT
This has already been covered a good bit in the command reference
section.
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.
Make sure there is plenty of space in cobbler's webdir, which defaults
to /var/www/cobbler.
cobbler reposync [--tries=N] [--no-fail]
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 usage 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 "cobbler 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.
For those familiar with yum's reposync, cobbler's reposync is (in most
uses) a wrapper around the yum command. Please use "cobbler reposync"
to update cobbler mirrors, as yum's reposync does not perform all
required steps. Also cobbler adds support for rsync and SSH locations,
where as yum's reposync only supports what yum supports (http/ftp).
If you ever want to update a certain repository you can run:
cobbler reposync --only="reponame1" ...
When updating repos by name, a repo will be updated even if it is set
to be not updated during a regular reposync operation (ex: cobbler repo
edit --name=reponame1 --keep-updated=0).
Note that if a cobbler import provides enough information to use the
boot server as a yum mirror for core packages, cobbler can set up
kickstarts to use the cobbler server as a mirror instead of the outside
world. If this feature is desirable, it can be turned on by setting
yum_post_install_mirror to 1 in /etc/settings ((and running "cobbler
sync"). You should not use this feature if machines are provisioned on
a different VLAN/network than production, or if you are provisioning
laptops that will want to acquire updates on multiple networks.
The flags --tries=N (for example, --tries=3) and --no-fail should
likely be used when putting reposync on a crontab. They ensure network
glitches in one repo can be retried and also that a failure to
synchronize one repo does not stop other repositories from being
synchronized.
PXE BOOT LOOP PREVENTION
If you have your machines set to PXE first in the boot order (ahead of
hard drives), change the "pxe_just_once" flag in /etc/cobbler/settings
to 1. This will set the machines to not PXE on successive boots once
they complete one install. To re-enable PXE for a specific system, run
the following command:
cobbler system edit --name=name --netboot-enabled=1
KICKSTART TRACKING
Cobbler knows how to keep track of the status of kickstarting machines.
cobbler status
Using the status command will show when cobbler thinks a machine
started kickstarting and when it finished, provided the proper snippets
are found in the kickstart template. This is a good way to track
machines that may have gone interactive (or stalled/crashed) during
kickstarts.
IMAGES
Cobbler can help with booting images physically and virtually, though
the usage of these commands varies substantially by the type of image.
Non-image based deployments are generally easier to work with and lead
to more sustaintable infrastructure. See
https://fedorahosted.org/cobbler/wiki/AllAboutImages for details on
things that are offered. Some manual use of other commands beyond of
what is typically required of cobbler may be needed to prepare images
for use with this feature.
TRIGGERS
Triggers provide a way to integrate cobbler with arbitrary 3rd party
software without modifying cobbler's code. When adding a distro,
profile, system, or repo, all scripts in /var/lib/cobbler/triggers/add
are executed for the particular object type. Each particular file must
be executable and it is executed with the name of the item being added
as a parameter. Deletions work similarly -- delete triggers live in
/var/lib/cobbler/triggers/delete. Order of execution is arbitrary, and
cobbler does not ship with any triggers by default. There are also
other kinds of triggers -- these are described on the Cobbler Wiki.
For larger configurations, triggers should be written in Python -- in
which case they are installed differently. This is also documented on
the Wiki.
API
Cobbler also makes itself available as an XMLRPC API for use by higher
level management software. Learn more at
http://fedorahosted.org/cobbler.
WEB USER INTERFACE
Most of the day-to-day actions in cobbler's command line can be
performed in Cobbler's Web UI. To enable and access the WebUI, see the
following documentation:
https://fedorahosted.org/cobbler/wiki/CobblerWebInterface
BOOT CD
Cobbler can build all of it's profiles into a bootable CD image using
the "cobbler buildiso" command. This allows for PXE-menu like bringup
of bare metal in evnvironments where PXE is not possible. Another more
advanced method is described in the koan manpage, though this method is
easier and sufficient for most applications.
POWER MANAGEMENT
Cobbler contains a power management feature that allows the user to
associate system records in cobbler with the power management
configuration attached to them. This can ease installation by making
it easy to reassign systems to new operating systems and then reboot
those systems. Read more about this feature at
https://fedorahosted.org/cobbler/wiki/PowerManagement
CONFIG MANAGEMENT INTEGRATION
Cobbler contains features for integrating an installation environment
with a configuration management system, which handles the configuration
of the system after it is installed by allowing changes to
configuration files and settings. You can read more about this feature
at https://fedorahosted.org/cobbler/wiki/BuiltinConfigManagement and
https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem.
Both features may be considered experimental as of time of the 1.4
release.
EXIT_STATUS
cobbler's command line returns a zero for success and non-zero for
failure.
ADDITIONAL RESOURCES
Cobbler has a mailing list for user and development-related
questions/comments at cobbler@lists.fedorahosted.org. To subscribe,
visit https://fedorahosted.org/mailman/listinfo/cobbler
IRC channel: irc.freenode.net (#cobbler)
Official web site, bug tracker, and Wiki:
http://fedorahosted.org/cobbler/
AUTHOR
Michael DeHaan <mdehaan@redhat.com>
POD ERRORS
Hey! The above document had some coding errors, which are explained
below:
Around line 548:
You forgot a '=back' before '=head3'
Around line 552:
=back without =over
2011-11-15 COBBLER(1)