.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .if !\nF .nr F 0 .if \nF>0 \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} .\} .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] \fP .\} .if t \{\ . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff .if n \{\ . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} .if t \{\ . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' .ds 8 \h'\*(#H'\(*b\h'-\*(#H' .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] .ds ae a\h'-(\w'a'u*4/10)'e .ds Ae A\h'-(\w'A'u*4/10)'E . \" corrections for vroff .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' . \" for low resolution devices (crt and lpr) .if \n(.H>23 .if \n(.V>19 \ \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} .rm #[ #] #H #V #F C .\" ======================================================================== .\" .IX Title "COBBLER.1 1" .TH COBBLER.1 1 "2016-02-12" "2.6.6" "man" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" cobbler \- a provisioning and update server .PP 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. .SH "SYNOPSIS" .IX Header "SYNOPSIS" cobbler command [subcommand] [\-\-arg1=value1] [\-\-arg2=value2] .SH "DESCRIPTION" .IX Header "DESCRIPTION" Cobbler manages provisioning using a tiered concept of Distributions, Profiles, Systems, and (optionally) Images and Repositories. .PP Distributions contain information about what kernel and initrd are used, plus metadata (required kernel parameters, etc). .PP Profiles associate a Distribution with a kickstart file and optionally customize the metadata further. .PP Systems associate a \s-1MAC, IP,\s0 and other networking details with a profile and optionally customize the metadata further. .PP Repositories contain yum mirror information. Using cobbler to mirror repositories is an optional feature, though provisioning and package management share a lot in common. .PP Images are a catch-all concept for things that do not play nicely in the \*(L"distribution\*(R" category. Most users will not need these records initially and these are described later in the document. .PP 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. .PP 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 \s-1API\s0 and \s-1XMLRPC\s0 components are available online at http://cobbler.github.io .PP Most users will be interested in the Web \s-1UI\s0 and should set it up, though the command line is needed for initial configuration \*(-- in particular \*(L"cobbler check\*(R" and \*(L"cobbler import\*(R", as well as the repo mirroring features. All of these are described later in the documentation. .SH "SEE ALSO" .IX Header "SEE ALSO" For help in building kickstarts, try using the \*(L"system-config-kickstart\*(R" 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. .PP Also see the aforementioned webpages for additional documentation, user contributed tips, and so on. .SH "COBBLER USAGE" .IX Header "COBBLER USAGE" .SS "\s-1SETUP\s0" .IX Subsection "SETUP" After installing, run \*(L"cobbler check\*(R" 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. .PP Any problems detected should be corrected, with the potential exception of \s-1DHCP\s0 related warnings where you will need to use your judgement as to whether they apply to your environment. Run \*(L"cobbler sync\*(R" after making any changes to the configuration files to ensure those changes are applied to the environment. .PP 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. .PP For \s-1PXE,\s0 if \s-1DHCP\s0 is to be run from the cobbler server, the dhcp configuration file should be changed as suggested by \*(L"cobbler check\*(R". If \s-1DHCP\s0 is not run locally, the \*(L"next-server\*(R" field on the \s-1DHCP\s0 server should at minimum point to the cobbler server's \s-1IP\s0 and the filename should be set to \*(L"pxelinux.0\*(R". 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 \s-1DHCP\s0 setup managed by some other tool, allowing cobbler to manage your \s-1DHCP\s0 environment will prove to be useful as it can manage \s-1DHCP\s0 reservations and other data. If you already have a \s-1DHCP\s0 setup, moving an existing setup to be managed from within cobbler is relatively painless \*(-- though usage of the \s-1DHCP\s0 management feature is entirely optional. If you are not interested in network booting via \s-1PXE\s0 and just want to use koan to install virtual systems or replace existing ones, \s-1DHCP\s0 configuration can be totally ignored. Koan also has a live \s-1CD \s0(see koan's manpage) capability that can be used to simulate \s-1PXE\s0 environments. .SS "\s-1DISTRIBUTIONS\s0" .IX Subsection "DISTRIBUTIONS" This first step towards configuring what you want to install is to add a distribution record to cobbler's configuration. .PP If there is an rsync mirror, \s-1DVD, NFS,\s0 or filesystem tree available that you would rather import instead, skip down to the documentation about the \*(L"import\*(R" 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. .PP If you want to be explicit with distribution definition, however, here's how it works: .PP \&\fBcobbler 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]\fR .IP "name" 4 .IX Item "name" a string identifying the distribution, this should be something like \*(L"rhel4\*(R". .IP "kernel" 4 .IX Item "kernel" An absolute filesystem path to a kernel image .IP "initrd" 4 .IX Item "initrd" An absolute filesystem path to a initrd image .IP "kopts" 4 .IX Item "kopts" Sets kernel command-line arguments that the distro, and profiles/systems depending 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 \*(L"!\*(R". .Sp Example: \-\-kopts=\*(L"foo=bar baz=3 asdf !gulp\*(R" .Sp This example passes the arguments \*(L"foo=bar baz=3 asdf\*(R" but will make sure \*(L"gulp\*(R" is not passed even if it was requested at a level higher up in the cobbler configuration. .IP "kopts-post" 4 .IX Item "kopts-post" This is just like \-\-kopts, though it governs kernel options on the installed \s-1OS,\s0 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. .Sp Example: \*(L"noapic\*(R" .IP "arch" 4 .IX Item "arch" Sets the architecture for the \s-1PXE\s0 bootloader and also controls how koan's \-\-replace\-self option will operate. .Sp 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. .Sp \&'x86' and 'x86_64' effectively do the same thing as standard. .Sp If you perform a cobbler import, the arch field will be auto-assigned. .IP "ksmeta" 4 .IX Item "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. .Sp Example: \-\-ksmeta=\*(L"foo=bar baz=3 asdf\*(R" .Sp See the section on \*(L"Kickstart Templating\*(R" for further information. .IP "breed" 4 .IX Item "breed" Controls how various physical and virtual parameters, including kernel arguments for automatic installation, are to be treated. Defaults to \*(L"redhat\*(R", which is a suitable value for Fedora and CentOS as well. It means anything redhat based. .Sp There is limited experimental support for specifying \*(L"debian\*(R", \*(L"ubuntu\*(R", or \*(L"suse\*(R", 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. .Sp 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 \*(L"kickstart\*(R", the kickstart parameter still governs where that answer file is. .IP "os-version" 4 .IX Item "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 \*(L"other\*(R" should be perfectly fine. Largely this is needed to support older distributions in virtualized settings, such as \*(L"rhel2.1\*(R", one of the \s-1OS\s0 choices if the breed is set to \*(L"redhat\*(R". If you do not encounter any problems with virtualized instances, this option can be safely ignored. .IP "owners" 4 .IX Item "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 \s-1XMLRPC\s0 interface, not the \*(L"cobbler\*(R" command line tool run from the shell. Furthermore, this is only respected by the \*(L"authz_ownership\*(R" module which must be enabled in /etc/cobbler/modules.conf. The value for \-\-owners is a space separated 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. .IP "template-files" 4 .IX Item "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. .IP "redhat-management-key" 4 .IX Item "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 \*(L"redhat_register\*(R" is included. Read more about setup in /etc/cobbler/settings. .SS "\s-1PROFILES\s0" .IX Subsection "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. .PP \&\fBcobbler 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] [\-\-parent=profile]\fR .PP Arguments are the same as listed for distributions, save for the removal of \*(L"arch\*(R" and \*(L"breed\*(R", and with the additions listed below: .IP "name" 4 .IX Item "name" A descriptive name. This could be something like \*(L"rhel5webservers\*(R" or \*(L"f9desktops\*(R". .IP "distro" 4 .IX Item "distro" The name of a previously defined cobbler distribution. This value is required. .IP "kickstart" 4 .IX Item "kickstart" Local filesystem path to a kickstart file. .Sp 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 \*(L"out of the box\*(R". Admins can change the default.ks if they desire. .Sp When using kickstart files, they must be placed in /var/lib/cobbler/kickstarts. If using the webapp to create new kickstarts, this is where the web application will put them. .IP "nameservers" 4 .IX Item "nameservers" If your nameservers are not provided by \s-1DHCP,\s0 you can specify a space separated 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 \s-1DHCP\s0 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. .IP "virt-file-size" 4 .IX Item "virt-file-size" (Virt-only) How large the disk image should be in Gigabytes. The default is \*(L"5\*(R". This can be a comma separated list (ex: \*(L"5,6,7\*(R") 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. .IP "virt-ram" 4 .IX Item "virt-ram" (Virt-only) How many megabytes of \s-1RAM\s0 to consume. The default is 512 \s-1MB. \s0 This should be input as an integer without units. .IP "virt-type" 4 .IX Item "virt-type" (Virt-only) Koan can install images using either Xen paravirt (\*(L"xenpv\*(R") or \s-1QEMU/KVM \s0(\*(L"qemu\*(R"). Choose one or the other strings to specify, or values will default to attempting to find a compatible installation type on the client system (\*(L"auto\*(R"). See the \*(L"koan\*(R" 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. .IP "virt-cpus" 4 .IX Item "virt-cpus" (Virt-only) How many virtual CPUs should koan give the virtual machine? The default is 1. This is an integer. .IP "virt-path" 4 .IX Item "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 \*(L"/dev/sda4\*(R" or volume groups \*(L"VolGroup00\*(R", etc. .Sp For multiple disks, separate the values with commas such as \*(L"VolGroup00,VolGroup00\*(R" or \*(L"/dev/sda4,/dev/sda5\*(R". Both those examples would create two disks for the \s-1VM.\s0 .IP "virt-bridge" 4 .IX Item "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 \s-1RPM\s0 is 'xenbr0'. If using \s-1KVM,\s0 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. .IP "repos" 4 .IX Item "repos" This is a space delimited list of all the repos (created with \*(L"cobbler repo add\*(R" and updated with \*(L"cobbler reposync\*(R") that this profile can make use of during kickstart installation. For example, an example might be \-\-repos=\*(L"fc6i386updates fc6i386extras\*(R" 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. .IP "parent" 4 .IX Item "parent" This is an advanced feature. .Sp Profiles may inherit from other profiles in lieu of specifying \-\-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. .Sp Example: If profile A has \-\-kopts=\*(L"x=7 y=2\*(R", B inherits from A, and B has \-\-kopts=\*(L"x=9 z=2\*(R", the actual kernel options that will be used for B are \*(L"x=9 y=2 z=2\*(R". .Sp 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. .IP "server" 4 .IX Item "server" 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 \s-1DHCP\s0 information of the system if you are also using Cobbler to help manage your \s-1DHCP\s0 configuration. .SS "\s-1SYSTEMS\s0" .IX Subsection "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 choosing a role for a specific system. .PP Note that if provisioning via koan and \s-1PXE\s0 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 \s-1MAC\s0 address. If there is a specific role intended for a given machine, system records should be created for it. .PP 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. .PP Read more about networking setup at: https://github.com/cobbler/cobbler/wiki/Advanced\-networking .PP \&\fBcobbler system add \-\-name=string \-\-profile=string [\-\-mac=macaddress] [\-\-ip\-address=ipaddress] [\-\-hostname=hostname] [\-\-kopts=string] [\-\-ksmeta=string] [\-\-kickstart=path] [\-\-netboot\-enabled=Y/N] [\-\-server=string] [\-\-gateway=string] [\-\-dns\-name=string] [\-\-static\-routes=string] [\-\-power\-address=string] [\-\-power\-type=string] [\-\-power\-user=string] [\-\-power\-pass=string] [\-\-power\-id=string]\fR .PP Adds a cobbler System to the configuration. Arguments are specified as per \*(L"profile add\*(R" with the following changes: .IP "name" 4 .IX Item "name" The system name works like the name option for other commands. .Sp If the name looks like a \s-1MAC\s0 address or an \s-1IP,\s0 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. .Sp A system created with name \*(L"default\*(R" has special semantics. If a default system object exists, it sets all undefined systems to \s-1PXE\s0 to a specific profile. Without a \*(L"default\*(R" system name created, \s-1PXE\s0 will fall through to local boot for unconfigured systems. .Sp When using \*(L"default\*(R" name, don't specify any other arguments than \-\-profile ... they won't be used. .IP "\-\-mac" 4 .IX Item "--mac" Specifying a mac address via \-\-mac allows the system object to boot directly to a specific profile via \s-1PXE,\s0 bypassing cobbler's \s-1PXE\s0 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. .Sp \&\s-1MAC\s0 addresses have the format \s-1AA:BB:CC:DD:EE:FF.\s0 It's highly recommended to register your MAC-addresses in Cobbler if you're using static addressing with multiple interfaces, or if you are using any of the advanced networking features like bonding, bridges or VLANs. .Sp 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 \s-1MAC\s0 addresses in your datacenter/lab configuration. .IP "\-\-ip\-address" 4 .IX Item "--ip-address" If cobbler is configured to generate a \s-1DHCP\s0 configuration (see advanced section), use this setting to define a specific \s-1IP\s0 for this system in \s-1DHCP. \s0 Leaving off this parameter will result in no \s-1DHCP\s0 management for this particular system. .Sp Example: \-\-ip\-address=192.168.1.50 .Sp Note for Itanium users: this setting is always required for \s-1IA64\s0 regardless of whether \s-1DHCP\s0 management is enabled. .Sp If \s-1DHCP\s0 management is disabled and the interface is labelled \-\-static=1, this setting will be used for static \s-1IP\s0 configuration. .Sp Special feature: To control the default \s-1PXE\s0 behavior for an entire subnet, this field can also be passed in using \s-1CIDR\s0 notation. If \-\-ip is \s-1CIDR,\s0 do not specify any other arguments other than \-\-name and \-\-profile. .Sp When using the \s-1CIDR\s0 notation trick, don't specify any arguments other than \-\-name and \-\-profile... they won't be used. .IP "\-\-dns\-name" 4 .IX Item "--dns-name" If using the \s-1DNS\s0 management feature (see advanced section \*(-- cobbler supports auto-setup of \s-1BIND\s0 and dnsmasq), use this to define a hostname for the system to receive from \s-1DNS.\s0 .Sp Example: \-\-dns\-name=mycomputer.example.com .Sp This is a per-interface parameter. If you have multiple interfaces, it may be different for each interface, for example, assume a \s-1DMZ /\s0 dual-homed setup. .IP "\-\-gateway and \-\-subnet" 4 .IX Item "--gateway and --subnet" If you are using static \s-1IP\s0 configurations and the interface is flagged \-\-static=1, these will be applied. .Sp Subnet is a per-interface parameter. Because of the way gateway is stored on the installed \s-1OS,\s0 gateway is a global parameter. You may use \-\-static\-routes for per-interface customizations if required. .IP "\-\-hostname" 4 .IX Item "--hostname" This field corresponds to the hostname set in a systems /etc/sysconfig/network file. This has no bearing on \s-1DNS,\s0 even when manage_dns is enabled. Use \-\-dns\-name instead for that feature. .Sp This parameter is assigned once per system, it is not a per-interface setting. .IP "\-\-power\-address, \-\-power\-type, \-\-power\-user, \-\-power\-pass, \-\-power\-id" 4 .IX Item "--power-address, --power-type, --power-user, --power-pass, --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://github.com/cobbler/cobbler/wiki/Power\-management. If you have a power-managed datacenter/lab setup, usage of these features may be something you are interested in. .IP "\-\-static" 4 .IX Item "--static" Indicates that this interface is statically configured. Many fields (such as gateway/subnet) will not be used unless this field is enabled. .Sp This is a per-interface setting. .IP "\-\-static\-routes" 4 .IX Item "--static-routes" This is a space delimited list of ip/mask:gateway routing information in that format. Most systems will not need this information. .Sp This is a per-interface setting. .IP "\-\-virt\-bridge" 4 .IX Item "--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. .Sp This is a per-interface setting. .IP "\-\-kickstart" 4 .IX Item "--kickstart" While it is recommended that the \-\-kickstart parameter is only used within for the \*(L"profile add\*(R" 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 specifying 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. .IP "\-\-netboot\-enabled" 4 .IX Item "--netboot-enabled" If set false, the system will be provisionable through koan but not through standard \s-1PXE. \s0 This will allow the system to fall back to default \s-1PXE\s0 boot behavior without deleting the cobbler system object. The default value allows \s-1PXE. \s0 Cobbler contains a \s-1PXE\s0 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 \s-1PXE\s0 first in the \s-1BIOS\s0 order. .IP "\-\-ldap\-enabled, \-\-ldap\-type" 4 .IX Item "--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. .IP "\-\-monit\-enabled" 4 .IX Item "--monit-enabled" If set true, koan will reload monit after each configuration run. The default value is false. .IP "\-\-repos\-enabled" 4 .IX Item "--repos-enabled" If set true, koan can reconfigure repositories after installation. This is described further on the Cobbler Wiki, https://github.com/cobbler/cobbler/wiki/Manage\-yum\-repos. .IP "\-\-dhcp\-tag" 4 .IX Item "--dhcp-tag" If you are setting up a \s-1PXE\s0 environment with multiple subnets/gateways, and are using cobbler to manage a \s-1DHCP\s0 configuration, you will probably want to use this option. If not, it can be ignored. .Sp By default, the dhcp tag for all systems is \*(L"default\*(R" and means that in the \s-1DHCP\s0 template files the systems will expand out where \f(CW$insert_cobbler_systems_definitions\fR is found in the \s-1DHCP\s0 template. However, you may want certain systems to expand out in other places in the \s-1DHCP\s0 config file. Setting \-\-dhcp\-tag=subnet2 for instance, will cause that system to expand out where \f(CW$insert_cobbler_system_definitions_subnet2\fR is found, allowing you to insert directives to specify different subnets (or other parameters) before the \s-1DHCP\s0 configuration entries for those particular systems. .Sp This is described further on the Cobbler Wiki. .IP "\-\-interface" 4 .IX Item "--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. .Sp Interface naming notes: .Sp 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 \s-1VLAN 5\s0 on interface eth0, simply name your interface eth0.5. .Sp Example: .Sp cobbler system edit \-\-name=foo \-\-ip\-address=192.168.1.50 \-\-mac=AA:BB:CC:DD:EE:A0 cobbler system edit \-\-name=foo \-\-interface=eth0 \-\-ip\-address=192.168.1.51 \-\-mac=AA:BB:CC:DD:EE:A1 cobbler system report foo .Sp Interfaces can be deleted using the \-\-delete\-interface option. .Sp Example: .Sp cobbler system edit \-\-name=foo \-\-interface=eth2 \-\-delete\-interface .IP "\-\-interface\-type, \-\-interface\-master and \-\-bonding\-opts/\-\-bridge\-opts" 4 .IX Item "--interface-type, --interface-master and --bonding-opts/--bridge-opts" One of the other advanced networking features supported by Cobbler is \s-1NIC\s0 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 \*(L"bond\*(R", \*(L"bond_slave\*(R", \*(L"bridge\*(R", \*(L"bridge_slave\*(R" and \*(L"bonded_bridge_slave\*(R". If one of the \*(L"_slave\*(R" 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=\*(L"foo=1 bar=2\*(R" or \-\-bridge\-opts=\*(L"foo=1 bar=2\*(R", respectively. .Sp Note: The options \*(L"master\*(R" and \*(L"slave\*(R" are deprecated, and are assumed to me \*(L"bond\*(R" and \*(L"bond_slave\*(R" when encountered. When a system object is saved, the deprecated values will be overwritten with the new, correct values. .Sp Example: .Sp 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=\*(L"mode=active\-backup miimon=100\*(R" \-\-ip\-address=192.168.0.63 \-\-subnet=255.255.255.0 \-\-gateway=192.168.0.1 \-\-static=1 .Sp More information about networking setup is available at https://github.com/cobbler/cobbler/wiki/Advanced\-networking .Sp To review what networking configuration you have for any object, run \*(L"cobbler system report\*(R" at any time: .Sp Example: .Sp cobbler system report \-\-name=foo .SS "\s-1REPOSITORIES\s0" .IX Subsection "REPOSITORIES" Repository mirroring allows cobbler to mirror not only install trees (\*(L"cobbler import\*(R" 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). .PP \&\fBcobbler 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]\fR .IP "mirror" 4 .IX Item "mirror" The address of the yum mirror. This can be an rsync:// \s-1URL,\s0 an ssh location, or a http:// or ftp:// mirror location. Filesystem paths also work. .Sp The mirror address should specify an exact repository to mirror \*(-- just one architecture and just one distribution. If you have a separate repo to mirror for a different arch, add that repo separately. .Sp Here's an example of what looks like a good \s-1URL:\s0 .Sp 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 \s-1SSH\s0) .Sp Experimental support is also provided for mirroring \s-1RHN\s0 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 \s-1RHEL5\s0 or later. You will also need a version of yum-utils equal or greater to 1.0.4. .IP "name" 4 .IX Item "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 \*(L"fc6i386updates\*(R". Again, be specific. .Sp This name corresponds with values given to the \-\-repos parameter of \*(L"cobbler profile add\*(R". 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 \*(L"yum_post_install_mirror\*(R" 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. .Sp Distros that can make use of yum repositories during kickstart include \s-1FC6\s0 and later, \s-1RHEL 5\s0 and later, and derivative distributions. .Sp See the documentation on \*(L"cobbler profile add\*(R" for more information. .IP "rpm-list" 4 .IX Item "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 \s-1FC6\s0 Extras, it may be desired to mirror just cobbler and koan, and skip all of the game packages. To do this, use \-\-rpm\-list=\*(L"cobbler koan\*(R". .Sp 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. .IP "createrepo-flags" 4 .IX Item "createrepo-flags" Specifies optional flags to feed into the createrepo tool, which is called when \*(L"cobbler reposync\*(R" is run for the given repository. The defaults are '\-c cache'. .IP "keep-updated" 4 .IX Item "keep-updated" Specifies that the named repository should not be updated during a normal \*(L"cobbler reposync\*(R". The repo may still be updated by name. The repo should be synced at least once before disabling this feature See \*(L"cobbler reposync\*(R" below. .IP "mirror-locally" 4 .IX Item "mirror-locally" When set to \*(L"N\*(R", 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. .IP "priority" 4 .IX Item "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. .IP "arch" 4 .IX Item "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). .IP "yumopts" 4 .IX Item "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 \*(L"alpha\*(R" and \*(L"beta\*(R", use something like \-\-yumopts=\*(L"alpha=2 beta=3\*(R". .IP "breed" 4 .IX Item "breed" Ordinarily cobbler's repo system will understand what you mean without supplying this parameter, though you can set it explicitly if needed. .SS "\s-1MANAGEMENT CLASSES\s0" .IX Subsection "MANAGEMENT CLASSES" Management classes allows cobbler to function as an configuration management system. Cobbler currently supports the following resource types: .IP "1. Packages" 4 .IX Item "1. Packages" .PD 0 .IP "2. Files" 4 .IX Item "2. Files" .PD .PP Resources are executed in the order listed above. .PP \&\fBcobbler mgmtclass add \-\-name=string \-\-comment=string [\-\-packages=list] [\-\-files=list]\fR .IP "name" 4 .IX Item "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=\*(L"madhatter\*(R" \-\-mgmt\-classes=\*(L"http mysql\*(R"). .IP "comment" 4 .IX Item "comment" A comment that describes the functions of the management class. .IP "packages" 4 .IX Item "packages" Specifies a list of package resources required by the management class. .IP "files" 4 .IX Item "files" Specifies a list of file resources required by the management class. .SH "MANAGEMENT RESOURCES" .IX Header "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. .IP "1. Packages" 4 .IX Item "1. Packages" .PD 0 .IP "2. Files" 4 .IX Item "2. Files" .PD .SS "\s-1PACKAGE RESOURCES\s0" .IX Subsection "PACKAGE RESOURCES" Package resources are managed using cobbler package add .PP \fIActions\fR .IX Subsection "Actions" .IP "install" 4 .IX Item "install" Install the package. [Default] .IP "uninstall" 4 .IX Item "uninstall" Uninstall the package. .PP \fIAttributes\fR .IX Subsection "Attributes" .IP "installer" 4 .IX Item "installer" Which package manager to use, vaild options [rpm|yum]. .IP "version" 4 .IX Item "version" Which version of the package to install. .PP \fIExamples\fR .IX Subsection "Examples" .PP \&\fBcobbler package add \-\-name=string \-\-comment=string [\-\-action=install|uninstall] \-\-installer=string [\-\-version=string]\fR .SS "\s-1FILE RESOURCES\s0" .IX Subsection "FILE RESOURCES" \fIActions\fR .IX Subsection "Actions" .IP "create" 4 .IX Item "create" Create the file. [Default] .IP "remove" 4 .IX Item "remove" Remove the file. .PP \fIAttributes\fR .IX Subsection "Attributes" .IP "mode" 4 .IX Item "mode" Permission mode (as in chmod). .IP "group" 4 .IX Item "group" The group owner of the file. .IP "user" 4 .IX Item "user" The user for the file. .IP "path" 4 .IX Item "path" The path for the file. .IP "template" 4 .IX Item "template" The template for the file. .PP \fIExamples\fR .IX Subsection "Examples" .PP \&\fBcobbler file add \-\-name=string \-\-comment=string [\-\-action=string] \-\-mode=string \-\-group=string \-\-owner=string \-\-path=string [\-\-template=string]\fR .SS "\s-1DISPLAYING CONFIGURATION ENTRIES\s0" .IX Subsection "DISPLAYING CONFIGURATION ENTRIES" The following commands are usable regardless of how you are using cobbler. \&\*(L"report\*(R" gives detailed configuration info. \*(L"list\*(R" just lists the names of items in the configuration. Run these commands to check how you have cobbler configured. .PP \&\fBcobbler list\fR .PP \&\fBcobbler distro|profile|system|repo|image|mgmtclass|package|file list\fR .PP \&\fBcobbler report\fR .PP \&\fBcobbler distro|profile|system|repo|image|mgmtclass|package|file report \-\-name=[object\-name]\fR .PP Alternatively, you could look at the configuration files in /var/lib/cobbler to see the same information. .SS "\s-1DELETING CONFIGURATION ENTRIES\s0" .IX Subsection "DELETING CONFIGURATION ENTRIES" If you want to remove a specific object, use the remove command with the name that was used to add it. .PP \&\fBcobbler distro remove \-\-name=string\fR .PP \&\fBcobbler profile remove \-\-name=string\fR .PP \&\fBcobbler system remove \-\-name=string\fR .PP \&\fBcobbler repo remove \-\-name=string\fR .PP \&\fBcobbler image remove \-\-name=string\fR .PP \&\fBcobbler mgmtclass remove \-\-name=string\fR .PP \&\fBcobbler package remove \-\-name=string\fR .PP \&\fBcobbler file remove \-\-name=string\fR .SS "\s-1EDITING\s0" .IX Subsection "EDITING" If you want to change a particular setting without doing an \*(L"add\*(R" again, use the \*(L"edit\*(R" 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. .PP \&\fBcobbler distro|profile|system|repo|image|mgmtclass|package|file edit \-\-name=string [parameterlist]\fR .SS "\s-1COPYING\s0" .IX Subsection "COPYING" Objects can also be copied: .PP \&\fBcobbler distro|profile|system|repo|image|mgmtclass|package|file copy \-\-name=oldname \-\-newname=newname\fR .SS "\s-1RENAMING\s0" .IX Subsection "RENAMING" Objects can also be renamed, as long as other objects don't reference them. .PP \&\fBcobbler distro|profile|system|repo|image|mgmtclass|package|file rename \-\-name=oldname \-\-newname=newname\fR .SS "\s-1REPLICATING\s0" .IX Subsection "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. .PP This feature is intended for load-balancing, disaster-recovery, backup, or multiple geography support. .PP \&\fBcobbler replicate \-\-master=cobbler.example.org [\-\-distros=pattern] [\-\-profiles=pattern] [\-\-systems=pattern] [\-\-repos\-pattern] [\-\-images=pattern] [\-\-prune] [\-\-omit\-data]\fR .PP Cobbler can replicate data from a central server. .PP Objects that need to be replicated should be specified with a pattern, such as \-\-profiles=\*(L"webservers* dbservers*\*(R" or \-\-systems=\*(L"*.example.org\*(R". 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 \*(L"*.example.org\*(R" 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. .PP In the case where objects are more recent on the local server, those changes will not be overridden locally. .PP Common data locations will be rsync'ed from the master server unless \-\-omit\-data is specified. .PP 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. .SS "\s-1REBUILDING CONFIGURATIONS\s0" .IX Subsection "REBUILDING CONFIGURATIONS" \&\fBcobbler sync\fR .PP 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. .PP 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. .PP If using cobbler to manage a \s-1DHCP\s0 and/or \s-1DNS\s0 server (see the advanced section of this manpage), sync does need to be run after systems are added to regenerate and reload the \s-1DHCP/DNS\s0 configurations. .PP The sync process can also be kicked off from the web interface. .SH "EXAMPLES" .IX Header "EXAMPLES" .SS "\s-1IMPORT WORKFLOW\s0" .IX Subsection "IMPORT WORKFLOW" Import is a very useful command that makes starting out with cobbler very quick and easy. .PP This example shows how to create a provisioning infrastructure from a distribution mirror or \s-1DVD ISO.\s0 Then a default \s-1PXE\s0 configuration is created, so that by default systems will \s-1PXE\s0 boot into a fully automated install process for that distribution. .PP You can use a network rsync mirror, a mounted \s-1DVD\s0 location, or a tree you have available via a network filesystem. .PP 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 \*(L"fedora8\*(R" from an \s-1ISO,\s0 and it's an x86_64 \s-1ISO,\s0 specify \-\-arch=x86_64 and the distro will be named \*(L"fedora8\-x86_64\*(R" 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. .PP \&\fBcobbler check\fR .PP \&\fBcobbler import \-\-path=rsync://yourfavoritemirror.com/rhel/5/os/x86_64 \-\-name=rhel5 \-\-arch=x86_64\fR .PP # \s-1OR \s0 .PP \&\fBcobbler import \-\-path=/mnt/dvd \-\-name=rhel5 \-\-arch=x86_64\fR .PP # \s-1OR \s0(using an external \s-1NAS\s0 box without mirroring) .PP \&\fBcobbler import \-\-path=/path/where/filer/is/mounted \-\-name=anyname \-\-available\-as=nfs://nfs.example.org:/where/mounted/\fR .PP # wait for mirror to rsync... .PP \&\fBcobbler report\fR .PP \&\fBcobbler system add \-\-name=default \-\-profile=name_of_a_profile1\fR .PP \&\fBcobbler system add \-\-name=AA:BB:CC:DD:EE:FF \-\-profile=name_of_a_profile2\fR .PP \&\fBcobbler sync\fR .SS "NON-IMPORT (\s-1MANUAL\s0) \s-1WORKFLOW\s0" .IX Subsection "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. .PP \&\fBcobbler check\fR .PP \&\fBcobbler distro add \-\-name=rhel4u3 \-\-kernel=/dir1/vmlinuz \-\-initrd=/dir1/initrd.img\fR .PP \&\fBcobbler distro add \-\-name=fc5 \-\-kernel=/dir2/vmlinuz \-\-initrd=/dir2/initrd.img\fR .PP \&\fBcobbler profile add \-\-name=fc5webservers \-\-distro=fc5\-i386 \-\-kickstart=/dir4/kick.ks \-\-kopts=\*(L"something_to_make_my_gfx_card_work=42 some_other_parameter=foo\*(R"\fR .PP \&\fBcobbler profile add \-\-name=rhel4u3dbservers \-\-distro=rhel4u3 \-\-kickstart=/dir5/kick.ks\fR .PP \&\fBcobbler system add \-\-name=AA:BB:CC:DD:EE:FF \-\-profile=fc5\-webservers\fR .PP \&\fBcobbler system add \-\-name=AA:BB:CC:DD:EE:FE \-\-profile=rhel4u3\-dbservers\fR .PP \&\fBcobbler report\fR .SS "\s-1REPOSITORY MIRRORING WORKFLOW\s0" .IX Subsection "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. .PP \&\fBcobbler check\fR .PP # set up your cobbler distros here. .PP \&\fBcobbler repo add \-\-mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/ \-\-name=fc6i386updates\fR .PP \&\fBcobbler repo add \-\-mirror=http://mirrors.kernel.org/fedora/extras/6/i386/ \-\-name=fc6i386extras\fR .PP \&\fBcobbler reposync\fR .PP \&\fBcobbler profile add \-\-name=p1 \-\-distro=existing_distro_name \-\-kickstart=/var/lib/cobbler/kickstarts/kickstart_fc6.ks \-\-repos=\*(L"fc6i386updates fc6i386extras\*(R"\fR .SS "\s-1VIRTUALIZATION\s0" .IX Subsection "VIRTUALIZATION" For Virt, be sure the distro uses the correct kernel (if paravirt) and follow similar steps as above, adding additional parameters as desired: .PP \&\fBcobbler distro add \-\-name=fc7virt [options...]\fR .PP Specify reasonable values for the Virt image size (in \s-1GB\s0) and \s-1RAM\s0 requirements (in \s-1MB\s0): .PP \&\fBcobbler profile add \-\-name=virtwebservers \-\-distro=fc7virt \-\-kickstart=path \-\-virt\-file\-size=10 \-\-virt\-ram=512 [...]\fR .PP Define systems if desired. koan can also provision based on the profile name. .PP \&\fBcobbler system add \-\-name=AA:BB:CC:DD:EE:FE \-\-profile=virtwebservers [...]\fR .PP If you have just installed cobbler, be sure that the \*(L"cobblerd\*(R" service is running and that port 25151 is unblocked. .PP See the manpage for koan for the client side steps. .SH "ADVANCED TOPICS" .IX Header "ADVANCED TOPICS" .SS "\s-1PXE MENUS\s0" .IX Subsection "PXE MENUS" Cobbler will automatically generate \s-1PXE\s0 menus for all profiles it has defined. Running \*(L"cobbler sync\*(R" is required to generate and update these menus. .PP To access the menus, type \*(L"menu\*(R" at the \*(L"boot:\*(R" prompt while a system is \s-1PXE\s0 booting. If nothing is typed, the network boot will default to a local boot. If \*(L"menu\*(R" is typed, the user can then choose and provision any cobbler profile the system knows about. .PP If the association between a system (\s-1MAC\s0 address) and a profile is already known, it may be more useful to just use \*(L"system add\*(R" commands and declare that relationship in cobbler; however many use cases will prefer having a \s-1PXE\s0 system, especially when provisioning is done at the same time as installing new physical machines. .PP If this behavior is not desired, run \*(L"cobbler system add \-\-name=default \-\-profile=plugh\*(R" to default all \s-1PXE\s0 booting machines to get a new copy of the profile \*(L"plugh\*(R". To go back to the menu system, run \*(L"cobbler system remove \-\-name=default\*(R" and then \*(L"cobbler sync\*(R" to regenerate the menus. .PP When using \s-1PXE\s0 menu deployment exclusively, it is not necessary to make cobbler system records, although the two can easily be mixed. .PP 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. .SS "\s-1KICKSTART TEMPLATING\s0" .IX Subsection "KICKSTART TEMPLATING" The \-\-ksmeta options above require more explanation. .PP If and only if \-\-kickstart options reference filesystem URIs, \-\-ksmeta allows for templating of the kickstart files to achieve advanced functions. If the \-\-ksmeta option for a profile read \-\-ksmeta=\*(L"foo=7 bar=llama\*(R", anywhere in the kickstart file where the string \*(L"$bar\*(R" appeared would be replaced with the string \*(L"llama\*(R". .PP To apply these changes, \*(L"cobbler sync\*(R" must be run to generate custom kickstarts for each profile/system. .PP 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 .PP When working with Cheetah, be sure to escape any shell macros that look like \*(L"$(this)\*(R" with something like \*(L"\e$(this)\*(R" or errors may show up during the sync process. .PP The Cobbler Wiki also contains numerous Cheetah examples that should prove useful in using this feature. .SS "\s-1KICKSTART SNIPPETS\s0" .IX Subsection "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. .PP Snippets can also be overridden for specific profile names or system names. This is described on the Cobbler Wiki. .SS "\s-1KICKSTART VALIDATION\s0" .IX Subsection "KICKSTART VALIDATION" To check for potential errors in kickstarts, prior to installation, use \*(L"cobbler validateks\*(R". 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 \*(L"cobbler validateks\*(R" runs on the rendered kickstart output, not kickstart templates themselves. .SS "\s-1DHCP MANAGEMENT\s0" .IX Subsection "DHCP MANAGEMENT" Cobbler can optionally help you manage \s-1DHCP\s0 server. This feature is off by default. .PP Choose either \*(L"management = isc_and_bind\*(R" in /etc/cobbler/dhcp.template or \*(L"management = \*(R"dnsmasq\*(L" in /etc/cobbler/modules.conf. Then set \*(R"manage_dhcp" to 1 in /etc/cobbler/settings. .PP This allows \s-1DHCP\s0 to be managed via \*(L"cobbler system add\*(R" commands, when you specify the mac address and \s-1IP\s0 address for systems you add into cobbler. .PP 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 (\s-1ISC\s0 dhcpd or dnsmasq) work before proceeding. .PP If you already have \s-1DHCP\s0 configuration data that you would like to preserve (say \s-1DHCP\s0 was manually configured earlier), insert the relevant portions of it into the template file, as running \*(L"cobbler sync\*(R" will overwrite your previous configuration. .PP \&\s-1NOTE:\s0 Itanium systems names also need to be assigned to a distro that was created with the \*(L"\-\-arch=ia64\*(R" 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 \s-1PXE. \s0 This is due to an elilo limitation. .PP By default, the \s-1DHCP\s0 configuration file will be updated each time \*(L"cobbler sync\*(R" is run, and not until then, so it is important to remember to use \*(L"cobbler sync\*(R" when using this feature. .PP 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. .SS "\s-1DNS CONFIGURATION MANAGEMENT\s0" .IX Subsection "DNS CONFIGURATION MANAGEMENT" Cobbler can optionally manage \s-1DNS\s0 configuration using \s-1BIND\s0 and dnsmasq. .PP Choose either \*(L"management = isc_and_bind\*(R" or \*(L"management = dnsmasq\*(R" in /etc/cobbler/modules.conf and then enable manage_dns in /etc/cobbler/settings. .PP This feature is off by default. If using \s-1BIND,\s0 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). .PP If using \s-1BIND,\s0 Cobbler will use /etc/cobbler/named.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 \s-1BIND\s0 works before proceeding. .PP If using dnsmasq, the template is /etc/cobbler/dnsmasq.template. Read this file and understand how dnsmasq works before proceeding. .PP All managed files (whether zone files and named.conf for \s-1BIND,\s0 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. .SS "\s-1SERVICE DISCOVERY \s0(\s-1AVAHI\s0)" .IX Subsection "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. .SS "\s-1IMPORTING TREES\s0" .IX Subsection "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. .PP 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 \*(L"cobbler\*(R". 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. .PP Mirrored content is saved automatically in /var/www/cobbler/ks_mirror. .PP Example: \fBcobbler import \-\-path=rsync://mirrorserver.example.com/path/ \-\-name=fedora \-\-arch=x86\fR .PP Example2: \fBcobbler import \-\-path=root@192.168.1.10:/stuff \-\-name=bar\fR .PP Example3: \fBcobbler import \-\-path=/mnt/dvd \-\-name=baz \-\-arch=x86_64\fR .PP Example4: \fBcobbler import \-\-path=/path/to/stuff \-\-name=glorp\fR .PP Example5: \fBcobbler import \-\-path=/path/where/filer/is/mounted \-\-name=anyname \-\-available\-as=nfs://nfs.example.org:/where/mounted/\fR .PP Once imported, run a \*(L"cobbler list\*(R" or \*(L"cobbler report\*(R" to see what you've added. .PP By default, the rsync operations will exclude content of certain architectures, debug RPMs, and \s-1ISO\s0 images \*(-- to change what is excluded during an import, see /etc/cobbler/rsync.exclude. .PP 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 \s-1NAS\s0 box, or potentially on another partition on the same machine that is already accessible via http:// or ftp://. .PP For import methods using rsync, additional flags can be passed to rsync with the option \-\-rsync\-flags. .PP 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. .SS "\s-1DEFAULT PXE BOOT BEHAVIOR\s0" .IX Subsection "DEFAULT PXE BOOT BEHAVIOR" What happens when \s-1PXE\s0 booting a system when cobbler has no record of the system being booted? .PP By default, cobbler will configure \s-1PXE\s0 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. .PP An easy way to specify a default cobbler profile to \s-1PXE\s0 boot is to create a system named \*(L"default\*(R". This will cause /etc/cobbler/default.pxe to be ignored. To restore the previous behavior do a \*(L"cobbler system remove\*(R" on the \*(L"default\*(R" system. .PP \&\fBcobbler system add \-\-name=default \-\-profile=boot_this\fR .PP \&\fBcobbler system remove \-\-name=default\fR .PP As mentioned in earlier sections, it is also possible to control the default behavior for a specific network: .PP \&\fBcobbler system add \-\-name=network1 \-\-ip\-address=192.168.0.0/24 \-\-profile=boot_this\fR .SS "\s-1REPO MANAGEMENT\s0" .IX Subsection "REPO MANAGEMENT" This has already been covered a good bit in the command reference section. .PP 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. .PP Make sure there is plenty of space in cobbler's webdir, which defaults to /var/www/cobbler. .PP \&\fBcobbler reposync [\-\-tries=N] [\-\-no\-fail]\fR .PP Cobbler reposync is the command to use to update repos as configured with \*(L"cobbler repo add\*(R". 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 \*(L"cobbler reposync\*(R", 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. .PP For those familiar with yum's reposync, cobbler's reposync is (in most uses) a wrapper around the yum command. Please use \*(L"cobbler reposync\*(R" to update cobbler mirrors, as yum's reposync does not perform all required steps. Also cobbler adds support for rsync and \s-1SSH\s0 locations, where as yum's reposync only supports what yum supports (http/ftp). .PP If you ever want to update a certain repository you can run: .PP \&\fBcobbler reposync \-\-only=\*(L"reponame1\*(R" ...\fR .PP 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). .PP 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 \*(L"cobbler sync\*(R"). 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. .PP 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. .SS "\s-1PXE BOOT LOOP PREVENTION\s0" .IX Subsection "PXE BOOT LOOP PREVENTION" If you have your machines set to \s-1PXE\s0 first in the boot order (ahead of hard drives), change the \*(L"pxe_just_once\*(R" flag in /etc/cobbler/settings to 1. This will set the machines to not \s-1PXE\s0 on successive boots once they complete one install. To re-enable \s-1PXE\s0 for a specific system, run the following command: .PP \&\fBcobbler system edit \-\-name=name \-\-netboot\-enabled=1\fR .SS "\s-1KICKSTART TRACKING\s0" .IX Subsection "KICKSTART TRACKING" Cobbler knows how to keep track of the status of kickstarting machines. .PP \&\fBcobbler status\fR .PP 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. .SS "\s-1IMAGES\s0" .IX Subsection "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. 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. .SS "\s-1TRIGGERS\s0" .IX Subsection "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. .SS "\s-1API\s0" .IX Subsection "API" Cobbler also makes itself available as an \s-1XMLRPC API\s0 for use by higher level management software. Learn more at http://cobbler.github.io .SS "\s-1WEB USER INTERFACE\s0" .IX Subsection "WEB USER INTERFACE" Most of the day-to-day actions in cobbler's command line can be performed in Cobbler's Web \s-1UI. \s0 To enable and access the WebUI, see the following documentation: .PP https://github.com/cobbler/cobbler/wiki/Cobbler\-web\-interface .SS "\s-1BOOT CD\s0" .IX Subsection "BOOT CD" Cobbler can build all of it's profiles into a bootable \s-1CD\s0 image using the \*(L"cobbler buildiso\*(R" command. This allows for PXE-menu like bringup of bare metal in environments where \s-1PXE\s0 is not possible. Another more advanced method is described in the koan manpage, though this method is easier and sufficient for most applications. .SS "\s-1POWER MANAGEMENT\s0" .IX Subsection "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://github.com/cobbler/cobbler/wiki/Power\-management .SS "\s-1CONFIG MANAGEMENT INTEGRATION\s0" .IX Subsection "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://github.com/cobbler/cobbler/wiki/Built\-in\-configuration\-management and https://github.com/cobbler/cobbler/wiki/Using\-cobbler\-with\-a\-configuration\-management\-system. Both features may be considered experimental as of time of the 1.4 release. .SH "EXIT_STATUS" .IX Header "EXIT_STATUS" cobbler's command line returns a zero for success and non-zero for failure. .SH "ADDITIONAL RESOURCES" .IX Header "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 .PP \&\s-1IRC\s0 channel: irc.freenode.net (#cobbler) .PP Official web site, bug tracker, and Wiki: http://cobbler.github.io .SH "AUTHOR" .IX Header "AUTHOR" Michael DeHaan