1COBBLER(1) cobbler COBBLER(1)
2
6 cobbler - a provisioning and update server
7 cobbler is a provisioning (installation) and update server. It
9 supports deployments via PXE (network booting), virtualization (Xen,
10 QEMU/KVM, or VMware), and re-installs of existing Linux systems. The
11 latter two features are enabled by usage of 'koan' on the remote
12 system. Update server features include yum mirroring and integration
13 of those mirrors with kickstart. Cobbler has a command line interface,
14 Web UI, and extensive Python and XMLRPC APIs for integration with
15 external scripts and applications.
16
18 cobbler command [subcommand] [--arg1=value1] [--arg2=value2]
19
21 Cobbler manages provisioning using a tiered concept of Distributions,
22 Profiles, Systems, and (optionally) Images and Repositories.
23 Distributions contain information about what kernel and initrd are
25 used, plus metadata (required kernel parameters, etc).
26 Profiles associate a Distribution with a kickstart file and optionally
28 customize the metadata further.
29 Systems associate a MAC, IP, and other networking details with a
31 profile and optionally customize the metadata further.
32 Repositories contain yum mirror information. Using cobbler to mirror
34 repositories is an optional feature, though provisioning and package
35 management share a lot in common.
36 Images are a catch-all concept for things that do not play nicely in
38 the "distribution" category. Most users will not need these records
39 initially and these are described later in the document.
40 The main advantage of cobbler is that it glues together many disjoint
42 technologies and concepts and abstracts the user from the need to
43 understand them. It allows the systems administrator to concentrate
44 on what he needs to do, and not how it is done.
45 This manpage will focus on the cobbler command line tool for use in
47 configuring cobbler. There is also mention of the Cobbler WebUI which
48 is usable for day-to-day operation of Cobbler once
49 installed/configured. Docs on the API and XMLRPC components are
50 available online at http://fedorahosted.org/cobbler.
51 Most users will be interested in the Web UI and should set it up,
53 though the command line is needed for initial configuration -- in
54 particular "cobbler check" and "cobbler import", as well as the repo
55 mirroring features. All of these are described later in the
56 documentation.
57
59 For help in building kickstarts, try using the "system-config-
60 kickstart" tool, or install a new system and look at the
61 /root/anaconda-ks.cfg file left over from the installer. General
62 kickstart questions can also be asked at kickstart-list@redhat.com.
63 Cobbler ships some kickstart templates in /etc/cobbler that may also
64 prove helpful.
65 Also see the aforementioned webpages for additional documentation, user
67 contributed tips, and so on.
68
70 SETUP
71 After installing, run "cobbler check" to verify that cobbler's
72 ecosystem is configured correctly. Cobbler check will direct you on
73 how to modify it's config files using a text editor.
74 Any problems detected should be corrected, with the potential exception
76 of DHCP related warnings where you will need to use your judgement as
77 to whether they apply to your environment. Run "cobbler sync" after
78 making any changes to the configuration files to ensure those changes
79 are applied to the environment.
80 It is especially important that the server name field be accurate in
82 /etc/cobbler/settings, without this field being correct, kickstart
83 trees will not be found, and automated installations will fail.
84 For PXE, if DHCP is to be run from the cobbler server, the dhcp
86 configuration file should be changed as suggested by "cobbler check".
87 If DHCP is not run locally, the "next-server" field on the DHCP server
88 should at minimum point to the cobbler server's IP and the filename
89 should be set to "pxelinux.0". Alternatively, cobbler can also
90 generate your dhcp configuration file if you want to run dhcp locally
91 -- this is covered in a later section. If you don't already have a
92 DHCP setup managed by some other tool, allowing cobbler to manage your
93 DHCP environment will prove to be useful as it can manage DHCP
94 reservations and other data. If you already have a DHCP setup, moving
95 an existing setup to be managed from within cobbler is relatively
96 painless -- though usage of the DHCP management feature is entirely
97 optional. If you are not interested in network booting via PXE and
98 just want to use koan to install virtual systems or replace existing
99 ones, DHCP configuration can be totally ignored. Koan also has a live
100 CD (see koan's manpage) capability that can be used to simulate PXE
101 environments.
102 DISTRIBUTIONS
104 This first step towards configurating what you want to install is to
105 add a distribution record to cobbler's configuration.
106 If there is an rsync mirror, DVD, NFS, or filesystem tree available
108 that you would rather import instead, skip down to the documentation
109 about the "import" command. It's really a lot easier to follow the
110 import workflow -- it only requires waiting for the mirror content to
111 be copied and/or scanned. Imported mirrors also save time during
112 install since they don't have to hit external install sources.
113 If you want to be explicit with distribution definition, however,
115 here's how it works:
116 cobbler distro add --name=string --kernel=path --initrd=path
118 [--kopts=string] [--kopts-post=string] [--ksmeta=string]
119 [--arch=x86|x86_64|ia64] [--breed=redhat|debian|suse]
120 [--template-files=string]
121 name
123 a string identifying the distribution, this should be something
124 like "rhel4".
125 kernel
127 An absolute filesystem path to a kernel image
128 initrd
130 An absolute filesystem path to a initrd image
131 kopts
133 Sets kernel command-line arguments that the distro, and
134 profiles/systems dependant on it, will use. To remove a kernel
135 argument that may be added by a higher cobbler object (or in the
136 global settings), you can prefix it with a "!".
137 Example: --kopts="foo=bar baz=3 asdf !gulp"
139 This example passes the arguments "foo=bar baz=3 asdf" but will
141 make sure "gulp" is not passed even if it was requested at a level
142 higher up in the cobbler configuration.
143 kopts-post
145 This is just like --kopts, though it governs kernel options on the
146 installed OS, as opposed to kernel options fed to the installer.
147 The syntax is exactly the same. This requires some special
148 snippets to be found in your kickstart template in order for this
149 to work. Kickstart templating is described later on in this
150 document.
151 Example: "noapic"
153 arch
155 Sets the architecture for the PXE bootloader and also controls how
156 koan's --replace-self option will operate.
157 The default setting ('standard') will use pxelinux. Set to 'ia64'
159 to use elilo. 'ppc' and 'ppc64' use yaboot. 's390x' is not
160 PXEable, but koan supports it for reinstalls.
161 'x86' and 'x86_64' effectively do the same thing as standard.
163 If you perform a cobbler import, the arch field will be auto-
165 assigned.
166 ksmeta
168 This is an advanced feature that sets kickstart variables to
169 substitute, thus enabling kickstart files to be treated as
170 templates. Templates are powered using Cheetah and are described
171 further along in this manpage as well as on the Cobbler Wiki.
172 Example: --ksmeta="foo=bar baz=3 asdf"
174 See the section on "Kickstart Templating" for further information.
176 breed
178 Controls how various physical and virtual parameters, including
179 kernel arguments for automatic installation, are to be treated.
180 Defaults to "redhat", which is a suitable value for Fedora and
181 CentOS as well. It means anything redhat based.
182 There is limited experimental support for specifying "debian",
184 "ubuntu", or "suse", which treats the kickstart file as a different
185 format and changes the kernel arguments appropriately. Support
186 for other types of distributions is possible in the future. See
187 the Wiki for the latest information about support for these
188 distributions.
189 The file used for the answer file, regardless of the breed setting,
191 is the value used for --kickstart when creating the profile. In
192 other words, if another distro calls their answer file something
193 other than a "kickstart", the kickstart parameter still governs
194 where that answer file is.
195 os-version
197 Generally this field can be ignored. It is intended to alter some
198 hardware setup for virtualized instances when provisioning guests
199 with koan. The valid options for --os-version vary depending on
200 what is specified for --breed. If you specify an invalid option,
201 the error message will contain a list of valid os versions that can
202 be used. If you do not know the os version or it does not appear
203 in the list, omitting this argument or using "other" should be
204 perfectly fine. Largely this is needed to support older
205 distributions in virtualized settings, such as "rhel2.1", one of
206 the OS choices if the breed is set to "redhat". If you do not
207 encounter any problems with virtualized instances, this option can
208 be safely ignored.
209 owners
211 Users with small sites and a limited number of admins can probably
212 ignore this option. All cobbler objects (distros, profiles,
213 systems, and repos) can take a --owners parameter to specify what
214 cobbler users can edit particular objects. This only applies to
215 the Cobbler WebUI and XMLRPC interface, not the "cobbler" command
216 line tool run from the shell. Furthermore, this is only respected
217 by the "authz_ownership" module which must be enabled in
218 /etc/cobbler/modules.conf. The value for --owners is a space
219 seperated list of users and groups as specified in
220 /etc/cobbler/users.conf. For more information see the users.conf
221 file as well as the Cobbler Wiki. In the default Cobbler
222 configuration, this value is completely ignored, as is users.conf.
223 template-files
225 This feature allows cobbler to be used as a configuration
226 management system. The argument is a space delimited string of
227 key=value pairs. Each key is the path to a template file, each
228 value is the path to install the file on the system. This is
229 described in further detail on the Cobbler Wiki and is implemented
230 using special code in the post install. Koan also can retrieve
231 these files from a cobbler server on demand, effectively allowing
232 cobbler to function as a lightweight templated configuration
233 management system.
234 redhat-management-key
236 If you're using Red Hat Network, Red Hat Satellite Server, or
237 Spacewalk, you can store your authentication keys here and Cobbler
238 can add the neccessary authentication code to your kickstart where
239 the snippet named "redhat_register" is included. Read more about
240 setup in /etc/cobbler/settings.
241 PROFILES
243 A profile associates a distribution to additional specialized options,
244 such as a kickstart automation file. Profiles are the core unit of
245 provisioning and at least one profile must exist for every distribution
246 to be provisioned. A profile might represent, for instance, a web
247 server or desktop configuration. In this way, profiles define a role
248 to be performed.
249 cobbler profile add --name=string --distro=string [--kickstart=path]
251 [--kopts=string] [--ksmeta=string] [--virt-file-size=gigabytes]
252 [--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer]
253 [--virt-path=string] [--virt-bridge=string] [--server-override]
254 [--parent=profile]
255 Arguments are the same as listed for distributions, save for the
257 removal of "arch" and "breed", and with the additions listed below:
258 name
260 A descriptive name. This could be something like "rhel5webservers"
261 or "f9desktops".
262 distro
264 The name of a previously defined cobbler distribution. This value
265 is required.
266 kickstart
268 Local filesystem path to a kickstart file. http:// URLs (even
269 CGI's) are also accepted, but a local file path is recommended, so
270 that the kickstart templating engine can be taken advantage of.
271 If this parameter is not provided, the kickstart file will default
273 to /var/lib/cobbler/kickstarts/default.ks. This file is initially
274 blank, meaning default kickstarts are not automated "out of the
275 box". Admins can change the default.ks if they desire.
276 When using kickstart files, they can be placed anywhere on the
278 filesystem, but the recommended path is
279 /var/lib/cobbler/kickstarts. If using the webapp to create new
280 kickstarts, this is where the web application will put them.
281 nameservers
283 If your nameservers are not provided by DHCP, you can specify a
284 space seperated list of addresses here to configure each of the
285 installed nodes to use them (provided the kickstarts used are
286 installed on a per-system basis). Users with DHCP setups should
287 not need to use this option. This is available to set in profiles
288 to avoid having to set it repeatedly for each system record.
289 virt-file-size
291 (Virt-only) How large the disk image should be in Gigabytes. The
292 default is "5". This can be a space seperated list (ex: "5,6,7")
293 to allow for multiple disks of different sizes depending on what is
294 given to --virt-path. This should be input as a integer or decimal
295 value without units.
296 virt-ram
298 (Virt-only) How many megabytes of RAM to consume. The default is
299 512 MB. This should be input as an integer without units.
300 virt-type
302 (Virt-only) Koan can install images using either Xen paravirt
303 ("xenpv") or QEMU/KVM ("qemu"). Choose one or the other strings to
304 specify, or values will default to attempting to find a compatible
305 installation type on the client system ("auto"). See the "koan"
306 manpage for more documentation. The default virt-type can be
307 configured in the cobbler settings file such that this parameter
308 does not have to be provided. Other virtualization types are
309 supported, for information on those options (such as VMware), see
310 the Cobbler Wiki.
311 virt-cpus
313 (Virt-only) How many virtual CPUs should koan give the virtual
314 machine? The default is 1. This is an integer.
315 virt-path
317 (Virt-only) Where to store the virtual image on the host system.
318 Except for advanced cases, this parameter can usually be omitted.
319 For disk images, the value is usually an absolute path to an
320 existing directory with an optional file name component. There is
321 support for specifying partitions "/dev/sda4" or volume groups
322 "VolGroup00", etc.
323 For multiple disks, seperate the values with commas such as
325 "VolGroup00,VolGroup00" or "/dev/sda4,/dev/sda5". Both those
326 examples would create two disks for the VM.
327 virt-bridge
329 (Virt-only) This specifies the default bridge to use for all
330 systems defined under this profile. If not specified, it will
331 assume the default value in the cobbler settings file, which as
332 shipped in the RPM is 'xenbr0'. If using KVM, this is most likely
333 not correct. You may want to override this setting in the system
334 object. Bridge settings are important as they define how outside
335 networking will reach the guest. For more information on bridge
336 setup, see the Cobbler Wiki, where there is a section describing
337 koan usage.
338 repos
340 This is a space delimited list of all the repos (created with
341 "cobbler repo add" and updated with "cobbler reposync") that this
342 profile can make use of during kickstart installation. For
343 example, an example might be --repos="fc6i386updates fc6i386extras"
344 if the profile wants to access these two mirrors that are already
345 mirrored on the cobbler server. Repo management is described in
346 greater depth later in the manpage.
347 parent
349 This is an advanced feature.
350 Profiles may inherit from other profiles in lieu of specifing
352 --distro. Inherited profiles will override any settings specified
353 in their parent, with the exception of --ksmeta (templating) and
354 --kopts (kernel options), which will be blended together.
355 Example: If profile A has --kopts="x=7 y=2", B inherits from A,
357 and B has --kopts="x=9 z=2", the actual kernel options that will be
358 used for B are "x=9 y=2 z=2".
359 Example: If profile B has --virt-ram=256 and A has --virt-ram of
361 512, profile B will use the value 256. Example: If profile A has
362 a --virt-file-size of 5 and B does not specify a size, B will use
363 the value from A.
364 server-override
366 This parameter should be useful only in select circumstances. If
367 machines are on a subnet that cannot access the cobbler server
368 using the name/IP as configured in the cobbler settings file, use
369 this parameter to override that server name. See also --dhcp-tag
370 for configuring the next server and DHCP informmation of the system
371 if you are also using Cobbler to help manage your DHCP
372 configuration.
373 SYSTEMS
375 System records map a piece of hardware (or a virtual machine) with the
376 cobbler profile to be assigned to run on it. This may be thought of as
377 chosing a role for a specific system.
378 Note that if provisioning via koan and PXE menus alone, it is not
380 required to create system records in cobbler, though they are useful
381 when system specific customizations are required. One such
382 customization would be defining the MAC address. If there is a
383 specific role inteded for a given machine, system records should be
384 created for it.
385 System commands have a wider variety of control offered over network
387 details. In order to use these to the fullest possible extent, the
388 kickstart template used by cobbler must contain certain kickstart
389 snippets (sections of code specifically written for Cobbler to make
390 these values become reality). Compare your kickstart templates with
391 the stock ones in /var/lib/cobbler/kickstarts if you have upgraded, to
392 make sure you can take advantage of all options to their fullest
393 potential. If you are a new cobbler user, base your kickstarts off of
394 these templates. Non-kickstart based distributions, while supported by
395 Cobbler, may not be able to use all of these features.
396 Read more about networking setup at:
398 https://fedorahosted.org/cobbler/wiki/AdvancedNetworking
399 cobbler system add --name=string --profile=string [--mac=macaddress]
401 [--ip=ipaddress] [--hostname=hostname] [--kopts=string]
402 [--ksmeta=string] [--kickstart=path] [--netboot-enabled=Y/N]
403 [--server-override=string] [--gateway=string] [--dns-name=string]
404 [--static-routes=string] [--power-address=string] [--power-type=string]
405 [--power-user=string] [--power-password=string] [--power-id=string]
406 Adds a cobbler System to the configuration. Arguments are specified as
408 per "profile add" with the following changes:
409 name
411 The system name works like the name option for other commands.
412 If the name looks like a MAC address or an IP, the name will
414 implicitly be used for either --mac or --ip of the first interface,
415 respectively. However, it's usually better to give a descriptive
416 name -- don't rely on this behavior.
417 A system created with name "default" has special semantics. If a
419 default system object exists, it sets all undefined systems to PXE
420 to a specific profile. Without a "default" system name created,
421 PXE will fall through to local boot for unconfigured systems.
422 When using "default" name, don't specify any other arguments than
424 --profile ... they won't be used.
425 --mac
427 Specifying a mac address via --mac allows the system object to boot
428 directly to a specific profile via PXE, bypassing cobbler's PXE
429 menu. If the name of the cobbler system already looks like a mac
430 address, this is inferred from the system name and does not need to
431 be specified.
432 MAC addresses have the format AA:BB:CC:DD:EE:FF. It's higly
434 recommended to register your MAC-addresses in Cobbler if you're
435 using static adressing with multiple interfaces, or if you are
436 using any of the advanced networking features like bonding or
437 VLANs.
438 Cobbler does contain a feature (enabled in /etc/cobbler/settings)
440 that can automatically add new system records when it finds
441 profiles being provisioned on hardware it has seen before. This
442 may help if you do not have a report of all the MAC addresses in
443 your datacenter/lab configuration.
444 --ip
446 If cobbler is configured to generate a DHCP configuratition (see
447 advanced section), use this setting to define a specific IP for
448 this system in DHCP. Leaving off this parameter will result in no
449 DHCP management for this particular system.
450 Example: --ip=192.168.1.50
452 Note for Itanium users: this setting is always required for IA64
454 regardless of whether DHCP management is enabled.
455 If DHCP management is disabled and the interface is labelled
457 --static=1, this setting will be used for static IP configuration.
458 Special feature: To control the default PXE behavior for an entire
460 subnet, this field can also be passed in using CIDR notation. If
461 --ip is CIDR, do not specify any other arguments other than --name
462 and --profile.
463 When using the CIDR notation trick, don't specify any arguments
465 other than --name and --profile... they won't be used.
466 --dns-name
468 If using the DNS management feature (see advanced section --
469 cobbler supports auto-setup of BIND and dnsmasq), use this to
470 define a hostname for the system to receive from DNS.
471 Example: --dns-name=mycomputer.example.com
473 This is a per-interface parameter. If you have multiple
475 interfaces, it may be different for each interface, for example,
476 assume a DMZ / dual-homed setup.
477 --gateway and --subnet
479 If you are using static IP configurations and the interface is
480 flagged --static=1, these will be applied.
481 Subnet is a per-interface parameter. Because of the way gateway is
483 stored on the installed OS, gateway is a global parameter. You may
484 usse --static-routes for per-interface customizations if required.
485 --hostname
487 This field corresponds to the hostname set in a systems
488 /etc/sysconfig/network file. This has no bearing on DNS, even when
489 manage_dns is enabled. Use --dns-name instead for that feature.
490 This parameter is assigned once per system, it is not a per-
492 interface setting.
493 --power-address, --power-type, --power-user, --power-password,
495 --power-id
496 Cobbler contains features that enable integration with power
497 management for easier installation, reinstallation, and management
498 of machines in a datacenter environment. These parameters are
499 described online at
500 https://fedorahosted.org/cobbler/wiki/PowerManagement. If you have
501 a power-managed datacenter/lab setup, usage of these features may
502 be something you are interested in.
503 --static
505 Indicates that this interface is statically configured. Many
506 fields (such as gateway/subnet) will not be used unless this field
507 is enabled.
508 This is a per-interface setting.
510 --static-routes
512 This is a space delimited list of ip/mask:gateway routing
513 information in that format. Most systems will not need this
514 information.
515 This is a per-interface setting.
517 --virt-bridge
519 (Virt-only) While --virt-bridge is present in the profile object
520 (see above), here it works on an interface by interface basis.
521 For instance it would be possible to have --virt-bridge0=xenbr0 and
522 --virt-bridge1=xenbr1. If not specified in cobbler for each
523 interface, koan will use the value as specified in the profile for
524 each interface, which may not always be what is intended, but will
525 be sufficient in most cases.
526 This is a per-interface setting.
528 --kickstart
530 While it is recommended that the --kickstart parameter is only used
531 within for the "profile add" command, there are limited scenarios
532 when an install base switching to cobbler may have legacy
533 kickstarts created on a per-system basis (one kickstart for each
534 system, nothing shared) and may not want to immediately make use of
535 the cobbler templating system. This allows specifing a kickstart
536 for use on a per-system basis. Creation of a parent profile is
537 still required. If the kickstart is a filesystem location, it will
538 still be treated as a cobbler template.
539 --netboot-enabled
541 If set false, the system will be provisionable through koan but not
542 through standard PXE. This will allow the system to fall back to
543 default PXE boot behavior without deleting the cobbler system
544 object. The default value allows PXE. Cobbler contains a PXE
545 boot loop prevention feature (pxe_just_once, can be enabled in
546 /etc/cobbler/settings) that can automatically trip off this value
547 after a system gets done installing. This can prevent installs
548 from appearing in an endless loop when the system is set to PXE
549 first in the BIOS order.
550 --dhcp-tag
552 If you are setting up a PXE environment with multiple
553 subnets/gateways, and are using cobbler to manage a DHCP
554 configuration, you will probably want to use this option. If not,
555 it canbe ignored.
556 By default, the dhcp tag for all systems is "default" and means
558 that in the DHCP template files the systems will expand out where
559 $insert_cobbler_systems_definitions is found in the DHCP template.
560 However, you may want certain systems to expand out in other places
561 in the DHCP config file. Setting --dhcp-tag=subnet2 for instance,
562 will cause that system to expand out where
563 $insert_cobbler_system_definitions_subnet2 is found, allowing you
564 to insert directives to specify different subnets (or other
565 parameters) before the DHCP configuration entries for those
566 particular systems.
567 This is described further on the Cobbler Wiki.
569 --interface
571 By default flags like --ip, --mac, --dhcp-tag, --dns-name,
572 --subnet, --virt-bridge, and --static-routes operate on the first
573 network interface defined for a system (eth0). However, cobbler
574 supports an arbitrary number of interfaces. Using --interface=eth1
575 for instance, will allow creating and editing of a second
576 interface.
577 Interface naming notes:
579 Additional interfaces can be specified (for example: eth1, or any
581 name you like, as long as it does not conflict with any reserved
582 names such as kernel module names) for use with the edit command.
583 Defining VLANs this way is also supported, of you want to add VLAN
584 5 on interface eth0, simply name your interface eth0:5.
585 Example:
587 cobbler system edit --name=foo --ip=192.168.1.50
589 --mac=AA:BB:CC:DD:EE:A0 cobbler system edit --name=foo
590 --interface=eth0 --ip=192.168.1.51 --mac=AA:BB:CC:DD:EE:A1 cobbler
591 system report foo
592 Interfaces can be deleted using the --delete-interface option.
594 Example:
596 cobbler system edit --name=foo --interface=eth2 --delete-interface
598 --bonding, --bonding-master and --bonding-opts
600 One of the other advanced networking features supported by Cobbler
601 is NIC bonding. You can use this to bond multiple physical network
602 interfaces to one single logical interface to reduce single points
603 of failure in your network. Supported values for the --bonding
604 parameter are "master" and "slave". If "slave" is specified, you
605 also need to define the master-interface for this bond using
606 --bonding-master=INTERFACE. Bonding options for the master-
607 interface may be specified using --bonding-opts="foo=1 bar=2"
608 Example:
610 cobbler system edit --name=foo --interface=eth0
612 --mac=AA:BB:CC:DD:EE:00 --bonding=slave --bonding-master=bond0
613 cobbler system edit --name=foo --interface=eth1
614 --mac=AA:BB:CC:DD:EE:01 --bonding=slave --bonding-master=bond0
615 cobbler system edit --name=foo --interface=bond0 --bonding=master
616 --bonding-opts="mode=active-backup miimon=100" --ip=192.168.0.63
617 --subnet=255.255.255.0 --gateway=192.168.0.1 --static=1
618 More information about networking setup is available at
620 https://fedorahosted.org/cobbler/wiki/AdvancedNetworking
621 To review what networking configuration you have for any object,
623 run "cobbler system report" at any time:
624 Example:
626 cobbler system report --name=foo
628 REPOSITORIES
630 Repository mirroring allows cobbler to mirror not only install trees
631 ("cobbler import" does this for you) but also optional packages, 3rd
632 party content, and even updates. Mirroring all of this content
633 locally on your network will result in faster, more up-to-date
634 installations and faster updates. If you are only provisioning a home
635 setup, this will probably be overkill, though it can be very useful for
636 larger setups (labs, datacenters, etc).
637 cobbler repo add --mirror=url --name=string [--rpmlist=list]
639 [--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number]
640 [--arch=string] [--mirror-locally=Y/N] [--breed=yum|apt|rsync|rhn]
641 mirror
643 The addresss of the yum mirror. This can be an rsync:// URL, an
644 ssh location, or a http:// or ftp:// mirror location. Filesystem
645 paths also work.
646 The mirror address should specify an exact repository to mirror --
648 just one architecture and just one distribution. If you have a
649 seperate repo to mirror for a different arch, add that repo
650 seperately.
651 Here's an example of what looks like a good URL:
653 rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386
655 (for rsync protocol)
656 http://mirrors.kernel.org/fedora/extras/6/i386/ (for http://)
657 user@yourmirror.example.com/fedora-linux-core/updates/6/i386 (for
658 SSH)
659 Experimental support is also provided for mirroring RHN content
661 when you need a fast local mirror. The mirror syntax for this is
662 --mirror=rhn://channel-name and you must have entitlements for this
663 to work. This requires the cobbler server to be installed on RHEL5
664 or later. You will also need a version of yum-utils equal or
665 greater to 1.0.4.
666 name
668 This name is used as the save location for the mirror. If the
669 mirror represented, say, Fedora Core 6 i386 updates, a good name
670 would be "fc6i386updates". Again, be specific.
671 This name corresponds with values given to the --repos parameter of
673 "cobbler profile add". If a profile has a --repos value that
674 matches the name given here, that repo can be automatically set up
675 during provisioning (when supported) and installed systems will
676 also use the boot server as a mirror (unless
677 "yum_post_install_mirror" is disabled in the settings file). By
678 default the provisioning server will act as a mirror to systems it
679 installs, which may not be desirable for laptop configurations,
680 etc.
681 Distros that can make use of yum repositories during kickstart
683 include FC6 and later, RHEL 5 and later, and derivative
684 distributions.
685 See the documentation on "cobbler profile add" for more
687 information.
688 rpm-list
690 By specifying a space-delimited list of package names for
691 --rpm-list, one can decide to mirror only a part of a repo (the
692 list of packages given, plus dependencies). This may be helpful in
693 conserving time/space/bandwidth. For instance, when mirroring FC6
694 Extras, it may be desired to mirror just cobbler and koan, and skip
695 all of the game packages. To do this, use --rpm-list="cobbler
696 koan".
697 This option only works for http:// and ftp:// repositories (as it
699 is powered by yumdownloader). It will be ignored for other mirror
700 types, such as local paths and rsync:// mirrors.
701 createrepo-flags
703 Specifies optional flags to feed into the createrepo tool, which is
704 called when "cobbler reposync" is run for the given repository.
705 The defaults are '-c cache'.
706 keep-updated
708 Specifies that the named repository should not be updated during a
709 normal "cobbler reposync". The repo may still be updated by
710 name. The repo should be synced at least once before disabling
711 this feature See "cobbler reposync" below.
712 mirror-locally
714 When set to "N", specifies that this yum repo is to be referenced
715 directly via kickstarts and not mirrored locally on the cobbler
716 server. Only http:// and ftp:// mirror urls are supported when
717 using --mirror-locally=N, you cannot use filesystem URLs.
718 priority
720 Specifies the priority of the repository (the lower the number, the
721 higher the priority), which applies to installed machines using the
722 repositories that also have the yum priorities plugin installed.
723 The default priority for the plugin is 99, as is that of all
724 cobbler mirrored repositories.
725 arch
727 Specifies what architecture the repository should use. By default
728 the current system arch (of the server) is used, which may not be
729 desirable. Using this to override the default arch allows
730 mirroring of source repositories (using --arch=src).
731 yumopts
733 Sets values for additional yum options that the repo should use on
734 installed systems. For instance if a yum plugin takes a certain
735 parameter "alpha" and "beta", use something like --yumopts="alpha=2
736 beta=3".
737 breed
739 Ordinarily cobbler's repo system will understand what you mean
740 without supplying this parameter, though if you want to mirror a
741 destination source using apt, you'll need to supply "apt" as the
742 value for this parameter.
743 DISPLAYING CONFIGURATION ENTRIES
745 The following commands are usable regardless of how you are using
746 cobbler. "report" gives detailed configuration info. "list" just lists
747 the names of items in the configuration. Run these commands to check
748 how you have cobbler configured.
749 cobbler list
751 cobbler distro|profile|system|repo|image list
753 cobbler report
755 cobbler distro|profile|system|repo|image report --name=[object-name]
757 Alternatively, you could look at the configuration files in
759 /var/lib/cobbler to see the same information.
760 DELETING CONFIGURATION ENTRIES
762 If you want to remove a specific object, use the remove command with
763 the name that was used to add it.
764 cobbler distro remove --name=string
766 cobbler profile remove --name=string
768 cobbler system remove --name=string
770 cobbler repo remove --name=string
772 cobbler image remove --name=string
774 EDITING
776 If you want to change a particular setting without doing an "add"
777 again, use the "edit" command, using the same name you gave when you
778 added the item. Anything supplied in the parameter list will overwrite
779 the settings in the existing object, preserving settings not mentioned.
780 cobbler distro|profile|system|repo|image edit --name=string
782 [parameterlist]
783 COPYING
785 Objects can also be copied:
786 cobbler distro|profile|system|repo|image copy --name=oldname
788 --newname=newname
789 RENAMING
791 Objects can also be renamed, as long as other objects don't reference
792 them.
793 cobbler distro|profile|system|repo|image rename --name=oldname
795 --newname=newname
796 REPLICATING
798 Cobbler can replicate configurations from a master cobbler server.
799 Each cobbler server is still expected to have a locally relevant
800 /etc/cobbler/cobbler.conf and modules.conf, as these files are not
801 synced.
802 This feature is intended for load-balancing, disaster-recovery, backup,
804 or multiple geography support.
805 cobbler replicate --master=cobbler.example.org [--distros=pattern]
807 [--profiles=pattern] [--systems=pattern] [--repos-pattern]
808 [--images=pattern] [--prune] [--omit-data]
809 Cobbler can replicate data from a central server.
811 Objects that need to be replicated should be specified with a pattern,
813 such as --profiles="webservers* dbservers*" or
814 --systems="*.example.org". All objects matched by the pattern, and
815 all dependencies of those objects matched by the pattern (recursively)
816 will be transferred from the remote server to the central server. This
817 is to say if you intend to transfer "*.example.org" and the definition
818 of the systems have not changed, but a profile above them has changed,
819 the changes to that profile will also be transferred.
820 In the case where objects are more recent on the local server, those
822 changes will not be overridden locally.
823 Common data locations will be rsync'ed from the master server unless
825 --omit-data is specified.
826 To delete objects that are no longer present on the master server, use
828 --prune. Warning: this will delete all object types not present on
829 the remote server from the local server, and is recursive. If you use
830 prune, it is best to manage cobbler centrally and not expect changes
831 made on the slave servers to be preserved. It is not currently
832 possible to just prune objects of a specific type.
833 REBUILDING CONFIGURATIONS
835 cobbler sync
836 Cobbler sync is used to repair or rebuild the contents /tftpboot or
838 /var/www/cobbler when something has changed behind the scenes. It
839 brings the filesystem up to date with the configuration as understood
840 by cobbler.
841 Sync should be run whenever files in /var/lib/cobbler are manually
843 edited (which is not recommended except for the settings file) or when
844 making changes to kickstart files. In practice, this should not happen
845 often, though running sync too many times does not cause any adverse
846 effects.
847 If using cobbler to manage a DHCP and/or DNS server (see the advanced
849 section of this manpage), sync does need to be run after systems are
850 added to regenerate and reload the DHCP/DNS configurations.
851 The sync process can also be kicked off from the web interface.
853
855 IMPORT WORKFLOW
856 Import is a very useful command that makes starting out with cobbler
857 very quick and easy.
858 This example shows how to create a provisioning infrastructure from a
860 distribution mirror or DVD ISO. Then a default PXE configuration is
861 created, so that by default systems will PXE boot into a fully
862 automated install process for that distribution.
863 You can use a network rsync mirror, a mounted DVD location, or a tree
865 you have available via a network filesystem.
866 Import knows how to autodetect the architecture of what is being
868 imported, though to make sure things are named correctly, it's always a
869 good idea to specify --arch. For instance, if you import a
870 distribution named "fedora8" from an ISO, and it's an x86_64 ISO,
871 specify --arch=x86_64 and the distro will be named "fedora8-x86_64"
872 automatically, and the right architecture field will also be set on the
873 distribution object. If you are batch importing an entire mirror
874 (containing multiple distributions and arches), you don't have to do
875 this, as cobbler will set the names for things based on the paths it
876 finds.
877 cobbler check
879 cobbler import --path=rsync://yourfavoritemirror.com/foo --name=rhel5
881 --arch=x86
882 # OR
884 cobbler import --path=/mnt/dvd --name=rhel5 --arch=x86_64
886 # OR (using an eternal NAS box without mirroring)
888 cobbler import --path=/path/where/filer/is/mounted --name=anyname
890 --available-as=nfs://nfs.example.org:/where/mounted/
891 # wait for mirror to rsync...
893 cobbler report
895 cobbler system add --name=default --profile=name_of_a_profile1
897 cobbler system add --name=AA:BB:CC:DD:EE:FF
899 --profile=name_of_a_profile2
900 cobbler sync
902 NON-IMPORT (MANUAL) WORKFLOW
904 The following example uses a local kernel and initrd file (already
905 downloaded), and shows how profiles would be created using two
906 different kickstarts -- one for a web server configuration and one for
907 a database server. Then, a machine is assigned to each profile.
908 cobbler check
910 cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz
912 --initrd=/dir1/initrd.img
913 cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz
915 --initrd=/dir2/initrd.img
916 cobbler profile add --name=fc5webservers --distro=fc5-i386
918 --kickstart=/dir4/kick.ks
919 --kopts="something_to_make_my_gfx_card_work=42
920 some_other_parameter=foo"
921 cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3
923 --kickstart=/dir5/kick.ks
924 cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
926 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
928 cobbler report
930 REPOSITORY MIRRORING WORKFLOW
932 The following example shows how to set up a repo mirror for two
933 repositories, and create a profile that will auto install those
934 repository configurations on provisioned systems using that profile.
935 cobbler check
937 # set up your cobbler distros here.
939 cobbler repo add
941 --mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/
942 --name=fc6i386updates
943 cobbler repo add
945 --mirror=http://mirrors.kernel.org/fedora/extras/6/i386/
946 --name=fc6i386extras
947 cobbler reposync
949 cobbler profile add --name=p1 --distro=existing_distro_name
951 --kickstart=/etc/cobbler/kickstart_fc6.ks --repos="fc6i386updates
952 fc6i386extras"
953 VIRTUALIZATION
955 For Virt, be sure the distro uses the correct kernel (if paravirt) and
956 follow similar steps as above, adding additional parameters as desired:
957 cobbler distro add --name=fc7virt [options...]
959 Specify reasonable values for the Virt image size (in GB) and RAM
961 requirements (in MB):
962 cobbler profile add --name=virtwebservers --distro=fc7virt
964 --kickstart=path --virt-file-size=10 --virt-ram=512 [...]
965 Define systems if desired. koan can also provision based on the
967 profile name.
968 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers
970 [...]
971 If you have just installed cobbler, be sure that the "cobblerd" service
973 is running and that port 25151 is unblocked.
974 See the manpage for koan for the client side steps.
976
978 PXE MENUS
979 Cobbler will automatically generate PXE menus for all profiles it has
980 defined. Running "cobbler sync" is required to generate and update
981 these menus.
982 To access the menus, type "menu" at the "boot:" prompt while a system
984 is PXE booting. If nothing is typed, the network boot will default to
985 a local boot. If "menu" is typed, the user can then choose and
986 provision any cobbler profile the system knows about.
987 If the association between a system (MAC address) and a profile is
989 already known, it may be more useful to just use "system add" commands
990 and declare that relationship in cobbler; however many use cases will
991 prefer having a PXE system, especially when provisioning is done at the
992 same time as installing new physical machines.
993 If this behavior is not desired, run "cobbler system add --name=default
995 --profile=plugh" to default all PXE booting machines to get a new copy
996 of the profile "plugh". To go back to the menu system, run "cobbler
997 system remove --name=default" and then "cobbler sync" to regenerate the
998 menus.
999 When using PXE menu deployment exclusively, it is not neccessary to
1001 make cobbler system records, although the two can easily be mixed.
1002 Additionally, note that all files generated for the pxe menu
1004 configurations are templatable, so if you wish to change the color
1005 scheme or equivalent, see the files in /etc/cobbler.
1006 KICKSTART TEMPLATING
1008 The --ksmeta options above require more explanation.
1009 If and only if --kickstart options reference filesystem URLs, --ksmeta
1011 allows for templating of the kickstart files to achieve advanced
1012 functions. If the --ksmeta option for a profile read --ksmeta="foo=7
1013 bar=llama", anywhere in the kickstart file where the string "$bar"
1014 appeared would be replaced with the string "llama".
1015 To apply these changes, "cobbler sync" must be run to generate custom
1017 kickstarts for each profile/system.
1018 For NFS and HTTP kickstart URLs, the "--ksmeta" options will have no
1020 effect. This is a good reason to let cobbler manage your kickstart
1021 files, though the URL functionality is provided for integration with
1022 legacy infrastructure, possibly including web apps that already
1023 generate kickstarts.
1024 Templated kickstart files are processed by the templating
1026 program/package Cheetah, so anything you can do in a Cheetah template
1027 can be done to a kickstart template. Learn more at
1028 http://www.cheetahtemplate.org/learn.html
1029 When working with Cheetah, be sure to escape any shell macros that look
1031 like "$(this)" with something like "\$(this)" or errors may show up
1032 during the sync process.
1033 The Cobbler Wiki also contains numerous Cheetah examples that should
1035 prove useful in using this feature.
1036 KICKSTART SNIPPETS
1038 Anywhere a kickstart template mentions SNIPPET::snippet_name, the file
1039 named /var/lib/cobbler/snippets/snippet_name (if present) will be
1040 included automatically in the kickstart template. This serves as a way
1041 to recycle frequently used kickstart snippets without duplication.
1042 Snippets can contain templating variables, and the variables will be
1043 evaluated according to the profile and/or system as one would expect.
1044 Snippets can also be overridden for specific profile names or system
1046 names. This is described on the Cobbler Wiki.
1047 KICKSTART VALIDATION
1049 To check for potential errors in kickstarts, prior to installation, use
1050 "cobbler validateks". This function will check all profile and system
1051 kickstarts for detectable errors. Since pykickstart is not future-
1052 Anaconda-version aware, there may be some false positives. It should
1053 be noted that "cobbler validateks" runs on the rendered kickstart
1054 output, not kickstart templates themselves.
1055 DHCP MANAGEMENT
1057 Cobbler can optionally help you manage DHCP server. This feature is
1058 off by default.
1059 Choose either "management = isc_and_bind" in /etc/cobbler/dhcp.template
1061 or "management = "dnsmasq" in /etc/cobbler/modules.conf. Then set
1062 "manage_dhcp" to 1 in /etc/cobbler/settings.
1063 This allows DHCP to be managed via "cobbler system add" commands, when
1065 you specify the mac address and IP address for systems you add into
1066 cobbler.
1067 Depending on your choice, cobbler will use /etc/cobbler/dhcpd.template
1069 or /etc/cobbler/dnsmasq.template as a starting point. This file must
1070 be user edited for the user's particular networking environment. Read
1071 the file and understand how the particular app (ISC dhcpd or dnsmasq)
1072 work before proceeding.
1073 If you already have DHCP configuration data that you would like to
1075 preserve (say DHCP was manually configured earlier), insert the
1076 relevant portions of it into the template file, as running "cobbler
1077 sync" will overwrite your previous configuration.
1078 NOTE: Itanium systems names also need to be assigned to a distro that
1080 was created with the "--arch=ia64" parameter. If you have Itanium
1081 systems, you must (for now) choose 'dhcp_isc' for
1082 /etc/cobbler/modules.conf and manage_dhcp in the /etc/cobbler/settings
1083 file, and are required to use --ip when creating the system object in
1084 order for those systems to PXE. This is due to an elilo limitation.
1085 By default, the DHCP configuration file will be updated each time
1087 "cobbler sync" is run, and not until then, so it is important to
1088 remember to use "cobbler sync" when using this feature.
1089 If omapi_enabled is set to 1 in /etc/cobbler/settings, the need to sync
1091 when adding new system records can be eliminated. However, the omapi
1092 feature is experimental and is not recommended for most users.
1093 DNS CONFIGURATION MANAGEMENT
1095 Cobbler can optionally manage DNS configuration using BIND and dnsmasq.
1096 Choose either "management = isc_and_bind" or "management = dnsmasq" in
1098 /etc/cobbler/modules.conf and then enable manage_dns in
1099 /etc/cobbler/settings.
1100 This feature is off by default. If using BIND, you must define the
1102 zones to be managed with the options 'manage_forward_zones' and
1103 'manage_reverse_zones'. (See the Wiki for more information on this).
1104 If using BIND, Cobbler will use /etc/cobbler/bind.template and
1106 /etc/cobbler/zone.template as a starting point for the named.conf and
1107 individual zone files, respectively. You may drop zone-specific
1108 template files in /etc/cobbler/zone_templates/name-of-zone which will
1109 override the default. These files must be user edited for the user's
1110 particular networking environment. Read the file and understand how
1111 BIND works before proceeding.
1112 If using dnsmasq, the template is /etc/cobbler/dnsmasq.template. Read
1114 this file and understand how dnsmasq works before proceeding.
1115 All managed files (whether zone files and named.conf for BIND, or
1117 dnsmasq.conf for dnsmasq) will be updated each time ``cobbler sync'' is
1118 run, and not until then, so it is important to remember to use
1119 ``cobbler sync'' when using this feature.
1120 SERVICE DISCOVERY (AVAHI)
1122 If the avahi-tools package is installed, cobblerd will broadcast it's
1123 presence on the network, allowing it to be discovered by koan with the
1124 koan --server=DISCOVER parameter.
1125 IMPORTING TREES
1127 Cobbler can auto-add distributions and profiles from remote sources,
1128 whether this is a filesystem path or an rsync mirror. This can save a
1129 lot of time when setting up a new provisioning environment. Import is
1130 a feature that many users will want to take advantage of, and is very
1131 simple to use.
1132 After an import is run, cobbler will try to detect the distribution
1134 type and automatically assign kickstarts. By default, it will
1135 provision the system by erasing the hard drive, setting up eth0 for
1136 dhcp, and using a default password of "cobbler". If this is
1137 undesirable, edit the kickstart files in /etc/cobbler to do something
1138 else or change the kickstart setting after cobbler creates the profile.
1139 Mirrored content is saved automatically in /var/www/cobbler/ks_mirror.
1141 Example: cobbler import --path=rsync://mirrorserver.example.com/path/
1143 --name=fedora --arch=x86
1144 Example2: cobbler import --path=root@192.168.1.10:/stuff --name=bar
1146 Example3: cobbler import --path=/mnt/dvd --name=baz --arch=x86_64
1148 Example4: cobbler import --path=/path/to/stuff --name=glorp
1150 Example5: cobbler import --path=/path/where/filer/is/mounted
1152 --name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
1153 Once imported, run a "cobbler list" or "cobbler report" to see what
1155 you've added.
1156 By default, the rsync operations will exclude content of certain
1158 architectures, debug RPMs, and ISO images -- to change what is excluded
1159 during an import, see /etc/cobbler/rsync.exclude.
1160 Note that all of the import commands will mirror install tree content
1162 into /var/www/cobbler unless a network accessible location is given
1163 with --available-as. --available-as will be primarily used when
1164 importing distros stored on an external NAS box, or potentially on
1165 another partition on the same machine that is already accessible via
1166 http:// or ftp://.
1167 For import methods using rsync, additional flags can be passed to rsync
1169 with the option --rsync-flags.
1170 Should you want to force the usage of a specific cobbler kickstart
1172 template for all profiles created by an import, you can feed the option
1173 --kickstart to import, to bypass the built-in kickstart auto-detection.
1174 DEFAULT PXE BOOT BEHAVIOR
1176 What happens when PXE booting a system when cobbler has no record of
1177 the system being booted?
1178 By default, cobbler will configure PXE to boot to the contents of
1180 /etc/cobbler/default.pxe, which (if unmodified) will just fall through
1181 to the local boot process. Administrators can modify this file if they
1182 like to change that behavior.
1183 An easy way to specify a default cobbler profile to PXE boot is to
1185 create a system named "default". This will cause
1186 /etc/cobbler/default.pxe to be ignored. To restore the previous
1187 behavior do a "cobbler system remove" on the "default" system.
1188 cobbler system add --name=default --profile=boot_this
1190 cobbler system remove --name=default
1192 As mentioned in earlier sections, it is also possible to control the
1194 default behavior for a specific network:
1195 cobbler system add --name=network1 --ip=192.168.0.0/24
1197 --profile=boot_this
1198 REPO MANAGEMENT
1200 This has already been covered a good bit in the command reference
1201 section.
1202 Yum repository management is an optional feature, and is not required
1204 to provision through cobbler. However, if cobbler is configured to
1205 mirror certain repositories, it can then be used to associate profiles
1206 with those repositories. Systems installed under those profiles will
1207 then be autoconfigured to use these repository mirrors in
1208 /etc/yum.repos.d, and if supported (Fedora Core 6 and later) these
1209 repositories can be leveraged even within Anaconda. This can be useful
1210 if (A) you have a large install base, (B) you want fast installation
1211 and upgrades for your systems, or (C) have some extra software not in a
1212 standard repository but want provisioned systems to know about that
1213 repository.
1214 Make sure there is plenty of space in cobbler's webdir, which defaults
1216 to /var/www/cobbler.
1217 cobbler reposync [--tries=N] [--no-fail]
1219 Cobbler reposync is the command to use to update repos as configured
1221 with "cobbler repo add". Mirroring can take a long time, and usage of
1222 cobbler reposync prior to usage is needed to ensure provisioned systems
1223 have the files they need to actually use the mirrored repositories. If
1224 you just add repos and never run "cobbler reposync", the repos will
1225 never be mirrored. This is probably a command you would want to put on
1226 a crontab, though the frequency of that crontab and where the output
1227 goes is left up to the systems administrator.
1228 For those familiar with yum's reposync, cobbler's reposync is (in most
1230 uses) a wrapper around the yum command. Please use "cobbler reposync"
1231 to update cobbler mirrors, as yum's reposync does not perform all
1232 required steps. Also cobbler adds support for rsync and SSH locations,
1233 where as yum's reposync only supports what yum supports (http/ftp).
1234 If you ever want to update a certain repository you can run:
1236 cobbler reposync --only="reponame1" ...
1238 When updating repos by name, a repo will be updated even if it is set
1240 to be not updated during a regular reposync operation (ex: cobbler repo
1241 edit --name=reponame1 --keep-updated=0).
1242 Note that if a cobbler import provides enough information to use the
1244 boot server as a yum mirror for core packages, cobbler can set up
1245 kickstarts to use the cobbler server as a mirror instead of the outside
1246 world. If this feature is desirable, it can be turned on by setting
1247 yum_post_install_mirror to 1 in /etc/settings ((and running "cobbler
1248 sync"). You should not use this feature if machines are provisioned on
1249 a different VLAN/network than production, or if you are provisioning
1250 laptops that will want to acquire updates on multiple networks.
1251 The flags --tries=N (for example, --tries=3) and --no-fail should
1253 likely be used when putting reposync on a crontab. They ensure network
1254 glitches in one repo can be retried and also that a failure to
1255 synchronize one repo does not stop other repositories from being
1256 synchronized.
1257 PXE BOOT LOOP PREVENTION
1259 If you have your machines set to PXE first in the boot order (ahead of
1260 hard drives), change the "pxe_just_once" flag in /etc/cobbler/settings
1261 to 1. This will set the machines to not PXE on successive boots once
1262 they complete one install. To re-enable PXE for a specific system, run
1263 the following command:
1264 cobbler system edit --name=name --netboot-enabled=1
1266 KICKSTART TRACKING
1268 Cobbler knows how to keep track of the status of kickstarting machines.
1269 cobbler status
1271 Using the status command will show when cobbler thinks a machine
1273 started kickstarting and when it finished, provided the proper snippets
1274 are found in the kickstart template. This is a good way to track
1275 machines that may have gone interactive (or stalled/crashed) during
1276 kickstarts.
1277 IMAGES
1279 Cobbler can help with booting images physically and virtually, though
1280 the usage of these commands varies substantially by the type of image.
1281 Non-image based deployments are generally easier to work with and lead
1282 to more sustaintable infrastructure. See
1283 https://fedorahosted.org/cobbler/wiki/AllAboutImages for details on
1284 things that are offered. Some manual use of other commands beyond of
1285 what is typically required of cobbler may be needed to prepare images
1286 for use with this feature.
1287 TRIGGERS
1289 Triggers provide a way to integrate cobbler with arbitrary 3rd party
1290 software without modifying cobbler's code. When adding a distro,
1291 profile, system, or repo, all scripts in /var/lib/cobbler/triggers/add
1292 are executed for the particular object type. Each particular file must
1293 be executable and it is executed with the name of the item being added
1294 as a parameter. Deletions work similarly -- delete triggers live in
1295 /var/lib/cobbler/triggers/delete. Order of execution is arbitrary, and
1296 cobbler does not ship with any triggers by default. There are also
1297 other kinds of triggers -- these are described on the Cobbler Wiki.
1298 For larger configurations, triggers should be written in Python -- in
1299 which case they are installed differently. This is also documented on
1300 the Wiki.
1301 API
1303 Cobbler also makes itself available as an XMLRPC API for use by higher
1304 level management software. Learn more at
1305 http://fedorahosted.org/cobbler.
1306 WEB USER INTERFACE
1308 Most of the day-to-day actions in cobbler's command line can be
1309 performed in Cobbler's Web UI. To enable and access the WebUI, see the
1310 following documentation:
1311 https://fedorahosted.org/cobbler/wiki/CobblerWebInterface
1313 BOOT CD
1315 Cobbler can build all of it's profiles into a bootable CD image using
1316 the "cobbler buildiso" command. This allows for PXE-menu like bringup
1317 of bare metal in evnvironments where PXE is not possible. Another more
1318 advanced method is described in the koan manpage, though this method is
1319 easier and sufficient for most applications.
1320 POWER MANAGEMENT
1322 Cobbler contains a power management feature that allows the user to
1323 associate system records in cobbler with the power management
1324 configuration attached to them. This can ease installation by making
1325 it easy to reassign systems to new operating systems and then reboot
1326 those systems. Read more about this feature at
1327 https://fedorahosted.org/cobbler/wiki/PowerManagement
1328 CONFIG MANAGEMENT INTEGRATION
1330 Cobbler contains features for integrating an installation environment
1331 with a configuration management system, which handles the configuration
1332 of the system after it is installed by allowing changes to
1333 configuration files and settings. You can read more about this feature
1334 at https://fedorahosted.org/cobbler/wiki/BuiltinConfigManagement and
1335 https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem.
1336 Both features may be considered experimental as of time of the 1.4
1337 release.
1338
1340 cobbler's command line returns a zero for success and non-zero for
1341 failure.
1342
1344 Cobbler has a mailing list for user and development-related
1345 questions/comments at cobbler@lists.fedorahosted.org. To subscribe,
1346 visit https://fedorahosted.org/mailman/listinfo/cobbler
1347 IRC channel: irc.freenode.net (#cobbler)
1349 Official web site, bug tracker, and Wiki:
1351 http://fedorahosted.org/cobbler/
1352
1354 Michael DeHaan <mdehaan@redhat.com>
1355 2011-04-20 COBBLER(1)