1COBBLER.1(1) man COBBLER.1(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://cobbler.github.io
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 configuring what you want to install is to add
105 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 depending 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 separated 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]
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.
269 If this parameter is not provided, the kickstart file will default
271 to /var/lib/cobbler/kickstarts/default.ks. This file is initially
272 blank, meaning default kickstarts are not automated "out of the
273 box". Admins can change the default.ks if they desire.
274 When using kickstart files, they must be placed in
276 /var/lib/cobbler/kickstarts. If using the webapp to create new
277 kickstarts, this is where the web application will put them.
278 nameservers
280 If your nameservers are not provided by DHCP, you can specify a
281 space separated list of addresses here to configure each of the
282 installed nodes to use them (provided the kickstarts used are
283 installed on a per-system basis). Users with DHCP setups should
284 not need to use this option. This is available to set in profiles
285 to avoid having to set it repeatedly for each system record.
286 virt-file-size
288 (Virt-only) How large the disk image should be in Gigabytes. The
289 default is "5". This can be a comma separated list (ex: "5,6,7")
290 to allow for multiple disks of different sizes depending on what is
291 given to --virt-path. This should be input as a integer or decimal
292 value without units.
293 virt-ram
295 (Virt-only) How many megabytes of RAM to consume. The default is
296 512 MB. This should be input as an integer without units.
297 virt-type
299 (Virt-only) Koan can install images using either Xen paravirt
300 ("xenpv") or QEMU/KVM ("qemu"). Choose one or the other strings to
301 specify, or values will default to attempting to find a compatible
302 installation type on the client system ("auto"). See the "koan"
303 manpage for more documentation. The default virt-type can be
304 configured in the cobbler settings file such that this parameter
305 does not have to be provided. Other virtualization types are
306 supported, for information on those options (such as VMware), see
307 the Cobbler Wiki.
308 virt-cpus
310 (Virt-only) How many virtual CPUs should koan give the virtual
311 machine? The default is 1. This is an integer.
312 virt-path
314 (Virt-only) Where to store the virtual image on the host system.
315 Except for advanced cases, this parameter can usually be omitted.
316 For disk images, the value is usually an absolute path to an
317 existing directory with an optional file name component. There is
318 support for specifying partitions "/dev/sda4" or volume groups
319 "VolGroup00", etc.
320 For multiple disks, separate the values with commas such as
322 "VolGroup00,VolGroup00" or "/dev/sda4,/dev/sda5". Both those
323 examples would create two disks for the VM.
324 virt-bridge
326 (Virt-only) This specifies the default bridge to use for all
327 systems defined under this profile. If not specified, it will
328 assume the default value in the cobbler settings file, which as
329 shipped in the RPM is 'xenbr0'. If using KVM, this is most likely
330 not correct. You may want to override this setting in the system
331 object. Bridge settings are important as they define how outside
332 networking will reach the guest. For more information on bridge
333 setup, see the Cobbler Wiki, where there is a section describing
334 koan usage.
335 repos
337 This is a space delimited list of all the repos (created with
338 "cobbler repo add" and updated with "cobbler reposync") that this
339 profile can make use of during kickstart installation. For
340 example, an example might be --repos="fc6i386updates fc6i386extras"
341 if the profile wants to access these two mirrors that are already
342 mirrored on the cobbler server. Repo management is described in
343 greater depth later in the manpage.
344 parent
346 This is an advanced feature.
347 Profiles may inherit from other profiles in lieu of specifying
349 --distro. Inherited profiles will override any settings specified
350 in their parent, with the exception of --ksmeta (templating) and
351 --kopts (kernel options), which will be blended together.
352 Example: If profile A has --kopts="x=7 y=2", B inherits from A,
354 and B has --kopts="x=9 z=2", the actual kernel options that will be
355 used for B are "x=9 y=2 z=2".
356 Example: If profile B has --virt-ram=256 and A has --virt-ram of
358 512, profile B will use the value 256. Example: If profile A has
359 a --virt-file-size of 5 and B does not specify a size, B will use
360 the value from A.
361 server
363 This parameter should be useful only in select circumstances. If
364 machines are on a subnet that cannot access the cobbler server
365 using the name/IP as configured in the cobbler settings file, use
366 this parameter to override that server name. See also --dhcp-tag
367 for configuring the next server and DHCP information of the system
368 if you are also using Cobbler to help manage your DHCP
369 configuration.
370 SYSTEMS
372 System records map a piece of hardware (or a virtual machine) with the
373 cobbler profile to be assigned to run on it. This may be thought of as
374 choosing a role for a specific system.
375 Note that if provisioning via koan and PXE menus alone, it is not
377 required to create system records in cobbler, though they are useful
378 when system specific customizations are required. One such
379 customization would be defining the MAC address. If there is a
380 specific role intended for a given machine, system records should be
381 created for it.
382 System commands have a wider variety of control offered over network
384 details. In order to use these to the fullest possible extent, the
385 kickstart template used by cobbler must contain certain kickstart
386 snippets (sections of code specifically written for Cobbler to make
387 these values become reality). Compare your kickstart templates with
388 the stock ones in /var/lib/cobbler/kickstarts if you have upgraded, to
389 make sure you can take advantage of all options to their fullest
390 potential. If you are a new cobbler user, base your kickstarts off of
391 these templates. Non-kickstart based distributions, while supported by
392 Cobbler, may not be able to use all of these features.
393 Read more about networking setup at:
395 https://github.com/cobbler/cobbler/wiki/Advanced-networking
396 cobbler system add --name=string --profile=string [--mac=macaddress]
398 [--ip-address=ipaddress] [--hostname=hostname] [--kopts=string]
399 [--ksmeta=string] [--kickstart=path] [--netboot-enabled=Y/N]
400 [--server=string] [--gateway=string] [--dns-name=string]
401 [--static-routes=string] [--power-address=string] [--power-type=string]
402 [--power-user=string] [--power-pass=string] [--power-id=string]
403 Adds a cobbler System to the configuration. Arguments are specified as
405 per "profile add" with the following changes:
406 name
408 The system name works like the name option for other commands.
409 If the name looks like a MAC address or an IP, the name will
411 implicitly be used for either --mac or --ip of the first interface,
412 respectively. However, it's usually better to give a descriptive
413 name -- don't rely on this behavior.
414 A system created with name "default" has special semantics. If a
416 default system object exists, it sets all undefined systems to PXE
417 to a specific profile. Without a "default" system name created,
418 PXE will fall through to local boot for unconfigured systems.
419 When using "default" name, don't specify any other arguments than
421 --profile ... they won't be used.
422 --mac
424 Specifying a mac address via --mac allows the system object to boot
425 directly to a specific profile via PXE, bypassing cobbler's PXE
426 menu. If the name of the cobbler system already looks like a mac
427 address, this is inferred from the system name and does not need to
428 be specified.
429 MAC addresses have the format AA:BB:CC:DD:EE:FF. It's highly
431 recommended to register your MAC-addresses in Cobbler if you're
432 using static addressing with multiple interfaces, or if you are
433 using any of the advanced networking features like bonding, bridges
434 or VLANs.
435 Cobbler does contain a feature (enabled in /etc/cobbler/settings)
437 that can automatically add new system records when it finds
438 profiles being provisioned on hardware it has seen before. This
439 may help if you do not have a report of all the MAC addresses in
440 your datacenter/lab configuration.
441 --ip-address
443 If cobbler is configured to generate a DHCP configuration (see
444 advanced section), use this setting to define a specific IP for
445 this system in DHCP. Leaving off this parameter will result in no
446 DHCP management for this particular system.
447 Example: --ip-address=192.168.1.50
449 Note for Itanium users: this setting is always required for IA64
451 regardless of whether DHCP management is enabled.
452 If DHCP management is disabled and the interface is labelled
454 --static=1, this setting will be used for static IP configuration.
455 Special feature: To control the default PXE behavior for an entire
457 subnet, this field can also be passed in using CIDR notation. If
458 --ip is CIDR, do not specify any other arguments other than --name
459 and --profile.
460 When using the CIDR notation trick, don't specify any arguments
462 other than --name and --profile... they won't be used.
463 --dns-name
465 If using the DNS management feature (see advanced section --
466 cobbler supports auto-setup of BIND and dnsmasq), use this to
467 define a hostname for the system to receive from DNS.
468 Example: --dns-name=mycomputer.example.com
470 This is a per-interface parameter. If you have multiple
472 interfaces, it may be different for each interface, for example,
473 assume a DMZ / dual-homed setup.
474 --gateway and --subnet
476 If you are using static IP configurations and the interface is
477 flagged --static=1, these will be applied.
478 Subnet is a per-interface parameter. Because of the way gateway is
480 stored on the installed OS, gateway is a global parameter. You may
481 use --static-routes for per-interface customizations if required.
482 --hostname
484 This field corresponds to the hostname set in a systems
485 /etc/sysconfig/network file. This has no bearing on DNS, even when
486 manage_dns is enabled. Use --dns-name instead for that feature.
487 This parameter is assigned once per system, it is not a per-
489 interface setting.
490 --power-address, --power-type, --power-user, --power-pass, --power-id
492 Cobbler contains features that enable integration with power
493 management for easier installation, reinstallation, and management
494 of machines in a datacenter environment. These parameters are
495 described online at
496 https://github.com/cobbler/cobbler/wiki/Power-management. If you
497 have a power-managed datacenter/lab setup, usage of these features
498 may be something you are interested in.
499 --static
501 Indicates that this interface is statically configured. Many
502 fields (such as gateway/subnet) will not be used unless this field
503 is enabled.
504 This is a per-interface setting.
506 --static-routes
508 This is a space delimited list of ip/mask:gateway routing
509 information in that format. Most systems will not need this
510 information.
511 This is a per-interface setting.
513 --virt-bridge
515 (Virt-only) While --virt-bridge is present in the profile object
516 (see above), here it works on an interface by interface basis.
517 For instance it would be possible to have --virt-bridge0=xenbr0 and
518 --virt-bridge1=xenbr1. If not specified in cobbler for each
519 interface, koan will use the value as specified in the profile for
520 each interface, which may not always be what is intended, but will
521 be sufficient in most cases.
522 This is a per-interface setting.
524 --kickstart
526 While it is recommended that the --kickstart parameter is only used
527 within for the "profile add" command, there are limited scenarios
528 when an install base switching to cobbler may have legacy
529 kickstarts created on a per-system basis (one kickstart for each
530 system, nothing shared) and may not want to immediately make use of
531 the cobbler templating system. This allows specifying a kickstart
532 for use on a per-system basis. Creation of a parent profile is
533 still required. If the kickstart is a filesystem location, it will
534 still be treated as a cobbler template.
535 --netboot-enabled
537 If set false, the system will be provisionable through koan but not
538 through standard PXE. This will allow the system to fall back to
539 default PXE boot behavior without deleting the cobbler system
540 object. The default value allows PXE. Cobbler contains a PXE
541 boot loop prevention feature (pxe_just_once, can be enabled in
542 /etc/cobbler/settings) that can automatically trip off this value
543 after a system gets done installing. This can prevent installs
544 from appearing in an endless loop when the system is set to PXE
545 first in the BIOS order.
546 --ldap-enabled, --ldap-type
548 Cobbler contains features that enable ldap management for easier
549 configuration after system provisioning. If set true, koan will run
550 the ldap command as defined by the systems ldap_type. The default
551 value is false.
552 --monit-enabled
554 If set true, koan will reload monit after each configuration run.
555 The default value is false.
556 --repos-enabled
558 If set true, koan can reconfigure repositories after installation.
559 This is described further on the Cobbler Wiki,
560 https://github.com/cobbler/cobbler/wiki/Manage-yum-repos.
561 --dhcp-tag
563 If you are setting up a PXE environment with multiple
564 subnets/gateways, and are using cobbler to manage a DHCP
565 configuration, you will probably want to use this option. If not,
566 it can be ignored.
567 By default, the dhcp tag for all systems is "default" and means
569 that in the DHCP template files the systems will expand out where
570 $insert_cobbler_systems_definitions is found in the DHCP template.
571 However, you may want certain systems to expand out in other places
572 in the DHCP config file. Setting --dhcp-tag=subnet2 for instance,
573 will cause that system to expand out where
574 $insert_cobbler_system_definitions_subnet2 is found, allowing you
575 to insert directives to specify different subnets (or other
576 parameters) before the DHCP configuration entries for those
577 particular systems.
578 This is described further on the Cobbler Wiki.
580 --interface
582 By default flags like --ip, --mac, --dhcp-tag, --dns-name,
583 --subnet, --virt-bridge, and --static-routes operate on the first
584 network interface defined for a system (eth0). However, cobbler
585 supports an arbitrary number of interfaces. Using --interface=eth1
586 for instance, will allow creating and editing of a second
587 interface.
588 Interface naming notes:
590 Additional interfaces can be specified (for example: eth1, or any
592 name you like, as long as it does not conflict with any reserved
593 names such as kernel module names) for use with the edit command.
594 Defining VLANs this way is also supported, of you want to add VLAN
595 5 on interface eth0, simply name your interface eth0.5.
596 Example:
598 cobbler system edit --name=foo --ip-address=192.168.1.50
600 --mac=AA:BB:CC:DD:EE:A0 cobbler system edit --name=foo
601 --interface=eth0 --ip-address=192.168.1.51 --mac=AA:BB:CC:DD:EE:A1
602 cobbler system report foo
603 Interfaces can be deleted using the --delete-interface option.
605 Example:
607 cobbler system edit --name=foo --interface=eth2 --delete-interface
609 --interface-type, --interface-master and --bonding-opts/--bridge-opts
611 One of the other advanced networking features supported by Cobbler
612 is NIC bonding and bridging. You can use this to bond multiple
613 physical network interfaces to one single logical interface to
614 reduce single points of failure in your network, or to create
615 bridged interfaces for things like tunnels and virtual machine
616 networks. Supported values for the --interface-type parameter are
617 "bond", "bond_slave", "bridge", "bridge_slave" and
618 "bonded_bridge_slave". If one of the "_slave" options is specified,
619 you also need to define the master-interface for this bond using
620 --interface-master=INTERFACE. Bonding and bridge options for the
621 master-interface may be specified using --bonding-opts="foo=1
622 bar=2" or --bridge-opts="foo=1 bar=2", respectively.
623 Example:
625 cobbler system edit --name=foo --interface=eth0
627 --mac=AA:BB:CC:DD:EE:00 --interface-type=bond_slave
628 --interface-master=bond0 cobbler system edit --name=foo
629 --interface=eth1 --mac=AA:BB:CC:DD:EE:01
630 --interface-type=bond_slave --interface-master=bond0 cobbler system
631 edit --name=foo --interface=bond0 --interface-type=bond
632 --bonding-opts="mode=active-backup miimon=100"
633 --ip-address=192.168.0.63 --subnet=255.255.255.0
634 --gateway=192.168.0.1 --static=1
635 More information about networking setup is available at
637 https://github.com/cobbler/cobbler/wiki/Advanced-networking
638 To review what networking configuration you have for any object,
640 run "cobbler system report" at any time:
641 Example:
643 cobbler system report --name=foo
645 REPOSITORIES
647 Repository mirroring allows cobbler to mirror not only install trees
648 ("cobbler import" does this for you) but also optional packages, 3rd
649 party content, and even updates. Mirroring all of this content
650 locally on your network will result in faster, more up-to-date
651 installations and faster updates. If you are only provisioning a home
652 setup, this will probably be overkill, though it can be very useful for
653 larger setups (labs, datacenters, etc).
654 cobbler repo add --mirror=url --name=string [--rpmlist=list]
656 [--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number]
657 [--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn]
658 mirror
660 The address of the yum mirror. This can be an rsync:// URL, an ssh
661 location, or a http:// or ftp:// mirror location. Filesystem paths
662 also work.
663 The mirror address should specify an exact repository to mirror --
665 just one architecture and just one distribution. If you have a
666 separate repo to mirror for a different arch, add that repo
667 separately.
668 Here's an example of what looks like a good URL:
670 rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386
672 (for rsync protocol)
673 http://mirrors.kernel.org/fedora/extras/6/i386/ (for http://)
674 user@yourmirror.example.com/fedora-linux-core/updates/6/i386 (for
675 SSH)
676 Experimental support is also provided for mirroring RHN content
678 when you need a fast local mirror. The mirror syntax for this is
679 --mirror=rhn://channel-name and you must have entitlements for this
680 to work. This requires the cobbler server to be installed on RHEL5
681 or later. You will also need a version of yum-utils equal or
682 greater to 1.0.4.
683 name
685 This name is used as the save location for the mirror. If the
686 mirror represented, say, Fedora Core 6 i386 updates, a good name
687 would be "fc6i386updates". Again, be specific.
688 This name corresponds with values given to the --repos parameter of
690 "cobbler profile add". If a profile has a --repos value that
691 matches the name given here, that repo can be automatically set up
692 during provisioning (when supported) and installed systems will
693 also use the boot server as a mirror (unless
694 "yum_post_install_mirror" is disabled in the settings file). By
695 default the provisioning server will act as a mirror to systems it
696 installs, which may not be desirable for laptop configurations,
697 etc.
698 Distros that can make use of yum repositories during kickstart
700 include FC6 and later, RHEL 5 and later, and derivative
701 distributions.
702 See the documentation on "cobbler profile add" for more
704 information.
705 rpm-list
707 By specifying a space-delimited list of package names for
708 --rpm-list, one can decide to mirror only a part of a repo (the
709 list of packages given, plus dependencies). This may be helpful in
710 conserving time/space/bandwidth. For instance, when mirroring FC6
711 Extras, it may be desired to mirror just cobbler and koan, and skip
712 all of the game packages. To do this, use --rpm-list="cobbler
713 koan".
714 This option only works for http:// and ftp:// repositories (as it
716 is powered by yumdownloader). It will be ignored for other mirror
717 types, such as local paths and rsync:// mirrors.
718 createrepo-flags
720 Specifies optional flags to feed into the createrepo tool, which is
721 called when "cobbler reposync" is run for the given repository.
722 The defaults are '-c cache'.
723 keep-updated
725 Specifies that the named repository should not be updated during a
726 normal "cobbler reposync". The repo may still be updated by
727 name. The repo should be synced at least once before disabling
728 this feature See "cobbler reposync" below.
729 mirror-locally
731 When set to "N", specifies that this yum repo is to be referenced
732 directly via kickstarts and not mirrored locally on the cobbler
733 server. Only http:// and ftp:// mirror urls are supported when
734 using --mirror-locally=N, you cannot use filesystem URLs.
735 priority
737 Specifies the priority of the repository (the lower the number, the
738 higher the priority), which applies to installed machines using the
739 repositories that also have the yum priorities plugin installed.
740 The default priority for the plugin is 99, as is that of all
741 cobbler mirrored repositories.
742 arch
744 Specifies what architecture the repository should use. By default
745 the current system arch (of the server) is used, which may not be
746 desirable. Using this to override the default arch allows
747 mirroring of source repositories (using --arch=src).
748 yumopts
750 Sets values for additional yum options that the repo should use on
751 installed systems. For instance if a yum plugin takes a certain
752 parameter "alpha" and "beta", use something like --yumopts="alpha=2
753 beta=3".
754 breed
756 Ordinarily cobbler's repo system will understand what you mean
757 without supplying this parameter, though you can set it explicitly
758 if needed.
759 MANAGEMENT CLASSES
761 Management classes allows cobbler to function as an configuration
762 management system. Cobbler currently supports the following resource
763 types:
764 1. Packages
766 2. Files
767 Resources are executed in the order listed above.
769 cobbler mgmtclass add --name=string --comment=string [--packages=list]
771 [--files=list]
772 name
774 The name of the mgmtclass. Use this name when adding a management
775 class to a system, profile, or distro. To add a mgmtclass to an
776 existing system use something like (cobbler system edit
777 --name="madhatter" --mgmt-classes="http mysql").
778 comment
780 A comment that describes the functions of the management class.
781 packages
783 Specifies a list of package resources required by the management
784 class.
785 files
787 Specifies a list of file resources required by the management
788 class.
789
791 Resources are the lego blocks of configuration management. Resources
792 are grouped together via Management Classes, which are then linked to a
793 system. Cobbler supports two (2) resource types. Resources are
794 configured in the order listed below.
795 1. Packages
797 2. Files
798 PACKAGE RESOURCES
800 Package resources are managed using cobbler package add
801 Actions
803 install
805 Install the package. [Default]
806 uninstall
808 Uninstall the package.
809 Attributes
811 installer
813 Which package manager to use, vaild options [rpm|yum].
814 version
816 Which version of the package to install.
817 Examples
819 cobbler package add --name=string --comment=string
821 [--action=install|uninstall] --installer=string [--version=string]
822 FILE RESOURCES
824 Actions
825 create
827 Create the file. [Default]
828 remove
830 Remove the file.
831 Attributes
833 mode
835 Permission mode (as in chmod).
836 group
838 The group owner of the file.
839 user
841 The user for the file.
842 path
844 The path for the file.
845 template
847 The template for the file.
848 Examples
850 cobbler file add --name=string --comment=string [--action=string]
852 --mode=string --group=string --owner=string --path=string
853 [--template=string]
854 DISPLAYING CONFIGURATION ENTRIES
856 The following commands are usable regardless of how you are using
857 cobbler. "report" gives detailed configuration info. "list" just lists
858 the names of items in the configuration. Run these commands to check
859 how you have cobbler configured.
860 cobbler list
862 cobbler distro|profile|system|repo|image|mgmtclass|package|file list
864 cobbler report
866 cobbler distro|profile|system|repo|image|mgmtclass|package|file report
868 --name=[object-name]
869 Alternatively, you could look at the configuration files in
871 /var/lib/cobbler to see the same information.
872 DELETING CONFIGURATION ENTRIES
874 If you want to remove a specific object, use the remove command with
875 the name that was used to add it.
876 cobbler distro remove --name=string
878 cobbler profile remove --name=string
880 cobbler system remove --name=string
882 cobbler repo remove --name=string
884 cobbler image remove --name=string
886 cobbler mgmtclass remove --name=string
888 cobbler package remove --name=string
890 cobbler file remove --name=string
892 EDITING
894 If you want to change a particular setting without doing an "add"
895 again, use the "edit" command, using the same name you gave when you
896 added the item. Anything supplied in the parameter list will overwrite
897 the settings in the existing object, preserving settings not mentioned.
898 cobbler distro|profile|system|repo|image|mgmtclass|package|file edit
900 --name=string [parameterlist]
901 COPYING
903 Objects can also be copied:
904 cobbler distro|profile|system|repo|image|mgmtclass|package|file copy
906 --name=oldname --newname=newname
907 RENAMING
909 Objects can also be renamed, as long as other objects don't reference
910 them.
911 cobbler distro|profile|system|repo|image|mgmtclass|package|file rename
913 --name=oldname --newname=newname
914 REPLICATING
916 Cobbler can replicate configurations from a master cobbler server.
917 Each cobbler server is still expected to have a locally relevant
918 /etc/cobbler/cobbler.conf and modules.conf, as these files are not
919 synced.
920 This feature is intended for load-balancing, disaster-recovery, backup,
922 or multiple geography support.
923 cobbler replicate --master=cobbler.example.org [--distros=pattern]
925 [--profiles=pattern] [--systems=pattern] [--repos-pattern]
926 [--images=pattern] [--prune] [--omit-data]
927 Cobbler can replicate data from a central server.
929 Objects that need to be replicated should be specified with a pattern,
931 such as --profiles="webservers* dbservers*" or
932 --systems="*.example.org". All objects matched by the pattern, and
933 all dependencies of those objects matched by the pattern (recursively)
934 will be transferred from the remote server to the central server. This
935 is to say if you intend to transfer "*.example.org" and the definition
936 of the systems have not changed, but a profile above them has changed,
937 the changes to that profile will also be transferred.
938 In the case where objects are more recent on the local server, those
940 changes will not be overridden locally.
941 Common data locations will be rsync'ed from the master server unless
943 --omit-data is specified.
944 To delete objects that are no longer present on the master server, use
946 --prune. Warning: this will delete all object types not present on
947 the remote server from the local server, and is recursive. If you use
948 prune, it is best to manage cobbler centrally and not expect changes
949 made on the slave servers to be preserved. It is not currently
950 possible to just prune objects of a specific type.
951 REBUILDING CONFIGURATIONS
953 cobbler sync
954 Cobbler sync is used to repair or rebuild the contents /tftpboot or
956 /var/www/cobbler when something has changed behind the scenes. It
957 brings the filesystem up to date with the configuration as understood
958 by cobbler.
959 Sync should be run whenever files in /var/lib/cobbler are manually
961 edited (which is not recommended except for the settings file) or when
962 making changes to kickstart files. In practice, this should not happen
963 often, though running sync too many times does not cause any adverse
964 effects.
965 If using cobbler to manage a DHCP and/or DNS server (see the advanced
967 section of this manpage), sync does need to be run after systems are
968 added to regenerate and reload the DHCP/DNS configurations.
969 The sync process can also be kicked off from the web interface.
971
973 IMPORT WORKFLOW
974 Import is a very useful command that makes starting out with cobbler
975 very quick and easy.
976 This example shows how to create a provisioning infrastructure from a
978 distribution mirror or DVD ISO. Then a default PXE configuration is
979 created, so that by default systems will PXE boot into a fully
980 automated install process for that distribution.
981 You can use a network rsync mirror, a mounted DVD location, or a tree
983 you have available via a network filesystem.
984 Import knows how to autodetect the architecture of what is being
986 imported, though to make sure things are named correctly, it's always a
987 good idea to specify --arch. For instance, if you import a
988 distribution named "fedora8" from an ISO, and it's an x86_64 ISO,
989 specify --arch=x86_64 and the distro will be named "fedora8-x86_64"
990 automatically, and the right architecture field will also be set on the
991 distribution object. If you are batch importing an entire mirror
992 (containing multiple distributions and arches), you don't have to do
993 this, as cobbler will set the names for things based on the paths it
994 finds.
995 cobbler check
997 cobbler import --path=rsync://yourfavoritemirror.com/rhel/5/os/x86_64
999 --name=rhel5 --arch=x86_64
1000 # OR
1002 cobbler import --path=/mnt/dvd --name=rhel5 --arch=x86_64
1004 # OR (using an external NAS box without mirroring)
1006 cobbler import --path=/path/where/filer/is/mounted --name=anyname
1008 --available-as=nfs://nfs.example.org:/where/mounted/
1009 # wait for mirror to rsync...
1011 cobbler report
1013 cobbler system add --name=default --profile=name_of_a_profile1
1015 cobbler system add --name=AA:BB:CC:DD:EE:FF
1017 --profile=name_of_a_profile2
1018 cobbler sync
1020 NON-IMPORT (MANUAL) WORKFLOW
1022 The following example uses a local kernel and initrd file (already
1023 downloaded), and shows how profiles would be created using two
1024 different kickstarts -- one for a web server configuration and one for
1025 a database server. Then, a machine is assigned to each profile.
1026 cobbler check
1028 cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz
1030 --initrd=/dir1/initrd.img
1031 cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz
1033 --initrd=/dir2/initrd.img
1034 cobbler profile add --name=fc5webservers --distro=fc5-i386
1036 --kickstart=/dir4/kick.ks
1037 --kopts="something_to_make_my_gfx_card_work=42
1038 some_other_parameter=foo"
1039 cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3
1041 --kickstart=/dir5/kick.ks
1042 cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
1044 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
1046 cobbler report
1048 REPOSITORY MIRRORING WORKFLOW
1050 The following example shows how to set up a repo mirror for two
1051 repositories, and create a profile that will auto install those
1052 repository configurations on provisioned systems using that profile.
1053 cobbler check
1055 # set up your cobbler distros here.
1057 cobbler repo add
1059 --mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/
1060 --name=fc6i386updates
1061 cobbler repo add
1063 --mirror=http://mirrors.kernel.org/fedora/extras/6/i386/
1064 --name=fc6i386extras
1065 cobbler reposync
1067 cobbler profile add --name=p1 --distro=existing_distro_name
1069 --kickstart=/var/lib/cobbler/kickstarts/kickstart_fc6.ks
1070 --repos="fc6i386updates fc6i386extras"
1071 VIRTUALIZATION
1073 For Virt, be sure the distro uses the correct kernel (if paravirt) and
1074 follow similar steps as above, adding additional parameters as desired:
1075 cobbler distro add --name=fc7virt [options...]
1077 Specify reasonable values for the Virt image size (in GB) and RAM
1079 requirements (in MB):
1080 cobbler profile add --name=virtwebservers --distro=fc7virt
1082 --kickstart=path --virt-file-size=10 --virt-ram=512 [...]
1083 Define systems if desired. koan can also provision based on the
1085 profile name.
1086 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers
1088 [...]
1089 If you have just installed cobbler, be sure that the "cobblerd" service
1091 is running and that port 25151 is unblocked.
1092 See the manpage for koan for the client side steps.
1094
1096 PXE MENUS
1097 Cobbler will automatically generate PXE menus for all profiles it has
1098 defined. Running "cobbler sync" is required to generate and update
1099 these menus.
1100 To access the menus, type "menu" at the "boot:" prompt while a system
1102 is PXE booting. If nothing is typed, the network boot will default to
1103 a local boot. If "menu" is typed, the user can then choose and
1104 provision any cobbler profile the system knows about.
1105 If the association between a system (MAC address) and a profile is
1107 already known, it may be more useful to just use "system add" commands
1108 and declare that relationship in cobbler; however many use cases will
1109 prefer having a PXE system, especially when provisioning is done at the
1110 same time as installing new physical machines.
1111 If this behavior is not desired, run "cobbler system add --name=default
1113 --profile=plugh" to default all PXE booting machines to get a new copy
1114 of the profile "plugh". To go back to the menu system, run "cobbler
1115 system remove --name=default" and then "cobbler sync" to regenerate the
1116 menus.
1117 When using PXE menu deployment exclusively, it is not necessary to make
1119 cobbler system records, although the two can easily be mixed.
1120 Additionally, note that all files generated for the pxe menu
1122 configurations are templatable, so if you wish to change the color
1123 scheme or equivalent, see the files in /etc/cobbler.
1124 KICKSTART TEMPLATING
1126 The --ksmeta options above require more explanation.
1127 If and only if --kickstart options reference filesystem URIs, --ksmeta
1129 allows for templating of the kickstart files to achieve advanced
1130 functions. If the --ksmeta option for a profile read --ksmeta="foo=7
1131 bar=llama", anywhere in the kickstart file where the string "$bar"
1132 appeared would be replaced with the string "llama".
1133 To apply these changes, "cobbler sync" must be run to generate custom
1135 kickstarts for each profile/system.
1136 Templated kickstart files are processed by the templating
1138 program/package Cheetah, so anything you can do in a Cheetah template
1139 can be done to a kickstart template. Learn more at
1140 http://www.cheetahtemplate.org/learn.html
1141 When working with Cheetah, be sure to escape any shell macros that look
1143 like "$(this)" with something like "\$(this)" or errors may show up
1144 during the sync process.
1145 The Cobbler Wiki also contains numerous Cheetah examples that should
1147 prove useful in using this feature.
1148 KICKSTART SNIPPETS
1150 Anywhere a kickstart template mentions SNIPPET::snippet_name, the file
1151 named /var/lib/cobbler/snippets/snippet_name (if present) will be
1152 included automatically in the kickstart template. This serves as a way
1153 to recycle frequently used kickstart snippets without duplication.
1154 Snippets can contain templating variables, and the variables will be
1155 evaluated according to the profile and/or system as one would expect.
1156 Snippets can also be overridden for specific profile names or system
1158 names. This is described on the Cobbler Wiki.
1159 KICKSTART VALIDATION
1161 To check for potential errors in kickstarts, prior to installation, use
1162 "cobbler validateks". This function will check all profile and system
1163 kickstarts for detectable errors. Since pykickstart is not future-
1164 Anaconda-version aware, there may be some false positives. It should
1165 be noted that "cobbler validateks" runs on the rendered kickstart
1166 output, not kickstart templates themselves.
1167 DHCP MANAGEMENT
1169 Cobbler can optionally help you manage DHCP server. This feature is
1170 off by default.
1171 Choose either "management = isc_and_bind" in /etc/cobbler/dhcp.template
1173 or "management = "dnsmasq" in /etc/cobbler/modules.conf. Then set
1174 "manage_dhcp" to 1 in /etc/cobbler/settings.
1175 This allows DHCP to be managed via "cobbler system add" commands, when
1177 you specify the mac address and IP address for systems you add into
1178 cobbler.
1179 Depending on your choice, cobbler will use /etc/cobbler/dhcpd.template
1181 or /etc/cobbler/dnsmasq.template as a starting point. This file must
1182 be user edited for the user's particular networking environment. Read
1183 the file and understand how the particular app (ISC dhcpd or dnsmasq)
1184 work before proceeding.
1185 If you already have DHCP configuration data that you would like to
1187 preserve (say DHCP was manually configured earlier), insert the
1188 relevant portions of it into the template file, as running "cobbler
1189 sync" will overwrite your previous configuration.
1190 NOTE: Itanium systems names also need to be assigned to a distro that
1192 was created with the "--arch=ia64" parameter. If you have Itanium
1193 systems, you must (for now) choose 'dhcp_isc' for
1194 /etc/cobbler/modules.conf and manage_dhcp in the /etc/cobbler/settings
1195 file, and are required to use --ip when creating the system object in
1196 order for those systems to PXE. This is due to an elilo limitation.
1197 By default, the DHCP configuration file will be updated each time
1199 "cobbler sync" is run, and not until then, so it is important to
1200 remember to use "cobbler sync" when using this feature.
1201 If omapi_enabled is set to 1 in /etc/cobbler/settings, the need to sync
1203 when adding new system records can be eliminated. However, the omapi
1204 feature is experimental and is not recommended for most users.
1205 DNS CONFIGURATION MANAGEMENT
1207 Cobbler can optionally manage DNS configuration using BIND and dnsmasq.
1208 Choose either "management = isc_and_bind" or "management = dnsmasq" in
1210 /etc/cobbler/modules.conf and then enable manage_dns in
1211 /etc/cobbler/settings.
1212 This feature is off by default. If using BIND, you must define the
1214 zones to be managed with the options 'manage_forward_zones' and
1215 'manage_reverse_zones'. (See the Wiki for more information on this).
1216 If using BIND, Cobbler will use /etc/cobbler/named.template and
1218 /etc/cobbler/zone.template as a starting point for the named.conf and
1219 individual zone files, respectively. You may drop zone-specific
1220 template files in /etc/cobbler/zone_templates/name-of-zone which will
1221 override the default. These files must be user edited for the user's
1222 particular networking environment. Read the file and understand how
1223 BIND works before proceeding.
1224 If using dnsmasq, the template is /etc/cobbler/dnsmasq.template. Read
1226 this file and understand how dnsmasq works before proceeding.
1227 All managed files (whether zone files and named.conf for BIND, or
1229 dnsmasq.conf for dnsmasq) will be updated each time ``cobbler sync'' is
1230 run, and not until then, so it is important to remember to use
1231 ``cobbler sync'' when using this feature.
1232 SERVICE DISCOVERY (AVAHI)
1234 If the avahi-tools package is installed, cobblerd will broadcast it's
1235 presence on the network, allowing it to be discovered by koan with the
1236 koan --server=DISCOVER parameter.
1237 IMPORTING TREES
1239 Cobbler can auto-add distributions and profiles from remote sources,
1240 whether this is a filesystem path or an rsync mirror. This can save a
1241 lot of time when setting up a new provisioning environment. Import is
1242 a feature that many users will want to take advantage of, and is very
1243 simple to use.
1244 After an import is run, cobbler will try to detect the distribution
1246 type and automatically assign kickstarts. By default, it will
1247 provision the system by erasing the hard drive, setting up eth0 for
1248 dhcp, and using a default password of "cobbler". If this is
1249 undesirable, edit the kickstart files in /etc/cobbler to do something
1250 else or change the kickstart setting after cobbler creates the profile.
1251 Mirrored content is saved automatically in /var/www/cobbler/ks_mirror.
1253 Example: cobbler import --path=rsync://mirrorserver.example.com/path/
1255 --name=fedora --arch=x86
1256 Example2: cobbler import --path=root@192.168.1.10:/stuff --name=bar
1258 Example3: cobbler import --path=/mnt/dvd --name=baz --arch=x86_64
1260 Example4: cobbler import --path=/path/to/stuff --name=glorp
1262 Example5: cobbler import --path=/path/where/filer/is/mounted
1264 --name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
1265 Once imported, run a "cobbler list" or "cobbler report" to see what
1267 you've added.
1268 By default, the rsync operations will exclude content of certain
1270 architectures, debug RPMs, and ISO images -- to change what is excluded
1271 during an import, see /etc/cobbler/rsync.exclude.
1272 Note that all of the import commands will mirror install tree content
1274 into /var/www/cobbler unless a network accessible location is given
1275 with --available-as. --available-as will be primarily used when
1276 importing distros stored on an external NAS box, or potentially on
1277 another partition on the same machine that is already accessible via
1278 http:// or ftp://.
1279 For import methods using rsync, additional flags can be passed to rsync
1281 with the option --rsync-flags.
1282 Should you want to force the usage of a specific cobbler kickstart
1284 template for all profiles created by an import, you can feed the option
1285 --kickstart to import, to bypass the built-in kickstart auto-detection.
1286 DEFAULT PXE BOOT BEHAVIOR
1288 What happens when PXE booting a system when cobbler has no record of
1289 the system being booted?
1290 By default, cobbler will configure PXE to boot to the contents of
1292 /etc/cobbler/default.pxe, which (if unmodified) will just fall through
1293 to the local boot process. Administrators can modify this file if they
1294 like to change that behavior.
1295 An easy way to specify a default cobbler profile to PXE boot is to
1297 create a system named "default". This will cause
1298 /etc/cobbler/default.pxe to be ignored. To restore the previous
1299 behavior do a "cobbler system remove" on the "default" system.
1300 cobbler system add --name=default --profile=boot_this
1302 cobbler system remove --name=default
1304 As mentioned in earlier sections, it is also possible to control the
1306 default behavior for a specific network:
1307 cobbler system add --name=network1 --ip-address=192.168.0.0/24
1309 --profile=boot_this
1310 REPO MANAGEMENT
1312 This has already been covered a good bit in the command reference
1313 section.
1314 Yum repository management is an optional feature, and is not required
1316 to provision through cobbler. However, if cobbler is configured to
1317 mirror certain repositories, it can then be used to associate profiles
1318 with those repositories. Systems installed under those profiles will
1319 then be autoconfigured to use these repository mirrors in
1320 /etc/yum.repos.d, and if supported (Fedora Core 6 and later) these
1321 repositories can be leveraged even within Anaconda. This can be useful
1322 if (A) you have a large install base, (B) you want fast installation
1323 and upgrades for your systems, or (C) have some extra software not in a
1324 standard repository but want provisioned systems to know about that
1325 repository.
1326 Make sure there is plenty of space in cobbler's webdir, which defaults
1328 to /var/www/cobbler.
1329 cobbler reposync [--tries=N] [--no-fail]
1331 Cobbler reposync is the command to use to update repos as configured
1333 with "cobbler repo add". Mirroring can take a long time, and usage of
1334 cobbler reposync prior to usage is needed to ensure provisioned systems
1335 have the files they need to actually use the mirrored repositories. If
1336 you just add repos and never run "cobbler reposync", the repos will
1337 never be mirrored. This is probably a command you would want to put on
1338 a crontab, though the frequency of that crontab and where the output
1339 goes is left up to the systems administrator.
1340 For those familiar with yum's reposync, cobbler's reposync is (in most
1342 uses) a wrapper around the yum command. Please use "cobbler reposync"
1343 to update cobbler mirrors, as yum's reposync does not perform all
1344 required steps. Also cobbler adds support for rsync and SSH locations,
1345 where as yum's reposync only supports what yum supports (http/ftp).
1346 If you ever want to update a certain repository you can run:
1348 cobbler reposync --only="reponame1" ...
1350 When updating repos by name, a repo will be updated even if it is set
1352 to be not updated during a regular reposync operation (ex: cobbler repo
1353 edit --name=reponame1 --keep-updated=0).
1354 Note that if a cobbler import provides enough information to use the
1356 boot server as a yum mirror for core packages, cobbler can set up
1357 kickstarts to use the cobbler server as a mirror instead of the outside
1358 world. If this feature is desirable, it can be turned on by setting
1359 yum_post_install_mirror to 1 in /etc/settings ((and running "cobbler
1360 sync"). You should not use this feature if machines are provisioned on
1361 a different VLAN/network than production, or if you are provisioning
1362 laptops that will want to acquire updates on multiple networks.
1363 The flags --tries=N (for example, --tries=3) and --no-fail should
1365 likely be used when putting reposync on a crontab. They ensure network
1366 glitches in one repo can be retried and also that a failure to
1367 synchronize one repo does not stop other repositories from being
1368 synchronized.
1369 PXE BOOT LOOP PREVENTION
1371 If you have your machines set to PXE first in the boot order (ahead of
1372 hard drives), change the "pxe_just_once" flag in /etc/cobbler/settings
1373 to 1. This will set the machines to not PXE on successive boots once
1374 they complete one install. To re-enable PXE for a specific system, run
1375 the following command:
1376 cobbler system edit --name=name --netboot-enabled=1
1378 KICKSTART TRACKING
1380 Cobbler knows how to keep track of the status of kickstarting machines.
1381 cobbler status
1383 Using the status command will show when cobbler thinks a machine
1385 started kickstarting and when it finished, provided the proper snippets
1386 are found in the kickstart template. This is a good way to track
1387 machines that may have gone interactive (or stalled/crashed) during
1388 kickstarts.
1389 IMAGES
1391 Cobbler can help with booting images physically and virtually, though
1392 the usage of these commands varies substantially by the type of image.
1393 Non-image based deployments are generally easier to work with and lead
1394 to more sustaintable infrastructure. Some manual use of other commands
1395 beyond of what is typically required of cobbler may be needed to
1396 prepare images for use with this feature.
1397 TRIGGERS
1399 Triggers provide a way to integrate cobbler with arbitrary 3rd party
1400 software without modifying cobbler's code. When adding a distro,
1401 profile, system, or repo, all scripts in /var/lib/cobbler/triggers/add
1402 are executed for the particular object type. Each particular file must
1403 be executable and it is executed with the name of the item being added
1404 as a parameter. Deletions work similarly -- delete triggers live in
1405 /var/lib/cobbler/triggers/delete. Order of execution is arbitrary, and
1406 cobbler does not ship with any triggers by default. There are also
1407 other kinds of triggers -- these are described on the Cobbler Wiki.
1408 For larger configurations, triggers should be written in Python -- in
1409 which case they are installed differently. This is also documented on
1410 the Wiki.
1411 API
1413 Cobbler also makes itself available as an XMLRPC API for use by higher
1414 level management software. Learn more at http://cobbler.github.io.
1415 WEB USER INTERFACE
1417 Most of the day-to-day actions in cobbler's command line can be
1418 performed in Cobbler's Web UI. To enable and access the WebUI, see the
1419 following documentation:
1420 https://github.com/cobbler/cobbler/wiki/Cobbler-web-interface
1422 BOOT CD
1424 Cobbler can build all of it's profiles into a bootable CD image using
1425 the "cobbler buildiso" command. This allows for PXE-menu like bringup
1426 of bare metal in environments where PXE is not possible. Another more
1427 advanced method is described in the koan manpage, though this method is
1428 easier and sufficient for most applications.
1429 POWER MANAGEMENT
1431 Cobbler contains a power management feature that allows the user to
1432 associate system records in cobbler with the power management
1433 configuration attached to them. This can ease installation by making
1434 it easy to reassign systems to new operating systems and then reboot
1435 those systems. Read more about this feature at
1436 https://github.com/cobbler/cobbler/wiki/Power-management
1437 CONFIG MANAGEMENT INTEGRATION
1439 Cobbler contains features for integrating an installation environment
1440 with a configuration management system, which handles the configuration
1441 of the system after it is installed by allowing changes to
1442 configuration files and settings. You can read more about this feature
1443 at
1444 https://github.com/cobbler/cobbler/wiki/Built-in-configuration-management
1445 and
1446 https://github.com/cobbler/cobbler/wiki/Using-cobbler-with-a-configuration-management-system.
1447 Both features may be considered experimental as of time of the 1.4
1448 release.
1449
1451 cobbler's command line returns a zero for success and non-zero for
1452 failure.
1453
1455 Cobbler has a mailing list for user and development-related
1456 questions/comments at cobbler@lists.fedorahosted.org. To subscribe,
1457 visit https://fedorahosted.org/mailman/listinfo/cobbler
1458 IRC channel: irc.freenode.net (#cobbler)
1460 Official web site, bug tracker, and Wiki: http://cobbler.github.io.
1462
1464 Michael DeHaan <michael.dehaan AT gmail>
14652.8.4 2018-11-17 COBBLER.1(1)