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 automated installation files. Cobbler has a
14 command line interface, Web UI, and extensive Python and XMLRPC APIs
15 for integration with 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 an automated installation
28 template file and optionally 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 https://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, automatic
83 installation trees will not be found, and automated installations will
84 fail.
85 For PXE, if DHCP is to be run from the cobbler server, the dhcp
87 configuration file should be changed as suggested by "cobbler check".
88 If DHCP is not run locally, the "next-server" field on the DHCP server
89 should at minimum point to the cobbler server's IP and the filename
90 should be set to "pxelinux.0". Alternatively, cobbler can also
91 generate your dhcp configuration file if you want to run dhcp locally
92 -- this is covered in a later section. If you don't already have a
93 DHCP setup managed by some other tool, allowing cobbler to manage your
94 DHCP environment will prove to be useful as it can manage DHCP
95 reservations and other data. If you already have a DHCP setup, moving
96 an existing setup to be managed from within cobbler is relatively
97 painless -- though usage of the DHCP management feature is entirely
98 optional. If you are not interested in network booting via PXE and
99 just want to use koan to install virtual systems or replace existing
100 ones, DHCP configuration can be totally ignored. Koan also has a live
101 CD (see koan's manpage) capability that can be used to simulate PXE
102 environments.
103 DISTRIBUTIONS
105 This first step towards configuring what you want to install is to add
106 a distribution record to cobbler's configuration.
107 If there is an rsync mirror, DVD, NFS, or filesystem tree available
109 that you would rather import instead, skip down to the documentation
110 about the "import" command. It's really a lot easier to follow the
111 import workflow -- it only requires waiting for the mirror content to
112 be copied and/or scanned. Imported mirrors also save time during
113 install since they don't have to hit external install sources.
114 If you want to be explicit with distribution definition, however,
116 here's how it works:
117 cobbler distro add --name=string --kernel=path --initrd=path
119 [--kopts=string] [--kopts-post=string] [--ksmeta=string]
120 [--arch=i386|x86_64|ppc|ppc64] [--breed=redhat|debian|suse]
121 [--template-files=string]
122 name
124 a string identifying the distribution, this should be something
125 like "rhel6".
126 kernel
128 An absolute filesystem path to a kernel image
129 initrd
131 An absolute filesystem path to a initrd image
132 kopts
134 Sets kernel command-line arguments that the distro, and
135 profiles/systems depending on it, will use. To remove a kernel
136 argument that may be added by a higher cobbler object (or in the
137 global settings), you can prefix it with a "!".
138 Example: --kopts="foo=bar baz=3 asdf !gulp"
140 This example passes the arguments "foo=bar baz=3 asdf" but will
142 make sure "gulp" is not passed even if it was requested at a level
143 higher up in the cobbler configuration.
144 kopts-post
146 This is just like --kopts, though it governs kernel options on the
147 installed OS, as opposed to kernel options fed to the installer.
148 The syntax is exactly the same. This requires some special
149 snippets to be found in your automatic installation template in
150 order for this to work. Automatic installation templating is
151 described later on in this document.
152 Example: "noapic"
154 arch
156 Sets the architecture for the PXE bootloader and also controls how
157 koan's --replace-self option will operate.
158 The default setting ('standard') will use pxelinux. Set to 'ppc'
160 and 'ppc64' to use yaboot.
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 automatic installation
169 template variables to substitute, thus enabling those files to be
170 treated as templates. Templates are powered using Cheetah and are
171 described further along in this manpage as well as on the Cobbler
172 Wiki.
173 Example: --ksmeta="foo=bar baz=3 asdf"
175 See the section on "Kickstart Templating" for further information.
177 breed
179 Controls how various physical and virtual parameters, including
180 kernel arguments for automatic installation, are to be treated.
181 Defaults to "redhat", which is a suitable value for Fedora and
182 CentOS as well. It means anything redhat based.
183 There is limited experimental support for specifying "debian",
185 "ubuntu", or "suse", which treats the automatic installation
186 template file as a preseed/autoyast file format and changes the
187 kernel arguments appropriately. Support for other types of
188 distributions is possible in the future. See the Wiki for the
189 latest information about support for these distributions.
190 The file used for the answer file, regardless of the breed setting,
192 is the value used for --autoinst when creating the profile.
193 os-version
195 Generally this field can be ignored. It is intended to alter some
196 hardware setup for virtualized instances when provisioning guests
197 with koan. The valid options for --os-version vary depending on
198 what is specified for --breed. If you specify an invalid option,
199 the error message will contain a list of valid os versions that can
200 be used. If you do not know the os version or it does not appear
201 in the list, omitting this argument or using "other" should be
202 perfectly fine. If you do not encounter any problems with
203 virtualized instances, this option can be safely ignored.
204 owners
206 Users with small sites and a limited number of admins can probably
207 ignore this option. All cobbler objects (distros, profiles,
208 systems, and repos) can take a --owners parameter to specify what
209 cobbler users can edit particular objects. This only applies to
210 the Cobbler WebUI and XMLRPC interface, not the "cobbler" command
211 line tool run from the shell. Furthermore, this is only respected
212 by the "authz_ownership" module which must be enabled in
213 /etc/cobbler/modules.conf. The value for --owners is a space
214 separated list of users and groups as specified in
215 /etc/cobbler/users.conf. For more information see the users.conf
216 file as well as the Cobbler Wiki. In the default Cobbler
217 configuration, this value is completely ignored, as is users.conf.
218 template-files
220 This feature allows cobbler to be used as a configuration
221 management system. The argument is a space delimited string of
222 key=value pairs. Each key is the path to a template file, each
223 value is the path to install the file on the system. This is
224 described in further detail on the Cobbler Wiki and is implemented
225 using special code in the post install. Koan also can retrieve
226 these files from a cobbler server on demand, effectively allowing
227 cobbler to function as a lightweight templated configuration
228 management system.
229 PROFILES
231 A profile associates a distribution to additional specialized options,
232 such as a installation automation file. Profiles are the core unit of
233 provisioning and at least one profile must exist for every distribution
234 to be provisioned. A profile might represent, for instance, a web
235 server or desktop configuration. In this way, profiles define a role
236 to be performed.
237 cobbler profile add --name=string --distro=string [--autoinst=path]
239 [--kopts=string] [--ksmeta=string] [--name-servers=string]
240 [--name-servers-search=string] [--virt-file-size=gigabytes]
241 [--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer]
242 [--virt-path=string] [--virt-bridge=string] [--server]
243 [--parent=profile]
244 Arguments are the same as listed for distributions, save for the
246 removal of "arch" and "breed", and with the additions listed below:
247 name
249 A descriptive name. This could be something like "rhel5webservers"
250 or "f9desktops".
251 distro
253 The name of a previously defined cobbler distribution. This value
254 is required.
255 autoinst
257 Local filesystem path to a automatic installation file, the file
258 must reside under /var/lib/cobbler/autoinstall_templates
259 name-servers
261 If your nameservers are not provided by DHCP, you can specify a
262 space separated list of addresses here to configure each of the
263 installed nodes to use them (provided the automatic installation
264 files used are installed on a per-system basis). Users with DHCP
265 setups should not need to use this option. This is available to
266 set in profiles to avoid having to set it repeatedly for each
267 system record.
268 name-servers-search
270 You can specify a space separated list of domain names to configure
271 each of the installed nodes to use them as domain search path.
272 This is available to set in profiles to avoid having to set it
273 repeatedly for each system record.
274 virt-file-size
276 (Virt-only) How large the disk image should be in Gigabytes. The
277 default is "5". This can be a comma separated list (ex: "5,6,7")
278 to allow for multiple disks of different sizes depending on what is
279 given to --virt-path. This should be input as a integer or decimal
280 value without units.
281 virt-ram
283 (Virt-only) How many megabytes of RAM to consume. The default is
284 512 MB. This should be input as an integer without units.
285 virt-type
287 (Virt-only) Koan can install images using either Xen paravirt
288 ("xenpv") or QEMU/KVM ("qemu"). Choose one or the other strings to
289 specify, or values will default to attempting to find a compatible
290 installation type on the client system ("auto"). See the "koan"
291 manpage for more documentation. The default virt-type can be
292 configured in the cobbler settings file such that this parameter
293 does not have to be provided. Other virtualization types are
294 supported, for information on those options (such as VMware), see
295 the Cobbler Wiki.
296 virt-cpus
298 (Virt-only) How many virtual CPUs should koan give the virtual
299 machine? The default is 1. This is an integer.
300 virt-path
302 (Virt-only) Where to store the virtual image on the host system.
303 Except for advanced cases, this parameter can usually be omitted.
304 For disk images, the value is usually an absolute path to an
305 existing directory with an optional file name component. There is
306 support for specifying partitions "/dev/sda4" or volume groups
307 "VolGroup00", etc.
308 For multiple disks, separate the values with commas such as
310 "VolGroup00,VolGroup00" or "/dev/sda4,/dev/sda5". Both those
311 examples would create two disks for the VM.
312 virt-bridge
314 (Virt-only) This specifies the default bridge to use for all
315 systems defined under this profile. If not specified, it will
316 assume the default value in the cobbler settings file, which as
317 shipped in the RPM is 'xenbr0'. If using KVM, this is most likely
318 not correct. You may want to override this setting in the system
319 object. Bridge settings are important as they define how outside
320 networking will reach the guest. For more information on bridge
321 setup, see the Cobbler Wiki, where there is a section describing
322 koan usage.
323 repos
325 This is a space delimited list of all the repos (created with
326 "cobbler repo add" and updated with "cobbler reposync") that this
327 profile can make use of during automated installation. For
328 example, an example might be --repos="fc6i386updates fc6i386extras"
329 if the profile wants to access these two mirrors that are already
330 mirrored on the cobbler server. Repo management is described in
331 greater depth later in the manpage.
332 parent
334 This is an advanced feature.
335 Profiles may inherit from other profiles in lieu of specifying
337 --distro. Inherited profiles will override any settings specified
338 in their parent, with the exception of --ksmeta (templating) and
339 --kopts (kernel options), which will be blended together.
340 Example: If profile A has --kopts="x=7 y=2", B inherits from A,
342 and B has --kopts="x=9 z=2", the actual kernel options that will be
343 used for B are "x=9 y=2 z=2".
344 Example: If profile B has --virt-ram=256 and A has --virt-ram of
346 512, profile B will use the value 256. Example: If profile A has
347 a --virt-file-size of 5 and B does not specify a size, B will use
348 the value from A.
349 server
351 This parameter should be useful only in select circumstances. If
352 machines are on a subnet that cannot access the cobbler server
353 using the name/IP as configured in the cobbler settings file, use
354 this parameter to override that server name. See also --dhcp-tag
355 for configuring the next server and DHCP information of the system
356 if you are also using Cobbler to help manage your DHCP
357 configuration.
358 SYSTEMS
360 System records map a piece of hardware (or a virtual machine) with the
361 cobbler profile to be assigned to run on it. This may be thought of as
362 choosing a role for a specific system.
363 Note that if provisioning via koan and PXE menus alone, it is not
365 required to create system records in cobbler, though they are useful
366 when system specific customizations are required. One such
367 customization would be defining the MAC address. If there is a
368 specific role intended for a given machine, system records should be
369 created for it.
370 System commands have a wider variety of control offered over network
372 details. In order to use these to the fullest possible extent, the
373 automatic installation template used by cobbler must contain certain
374 automatic installation snippets (sections of code specifically written
375 for Cobbler to make these values become reality). Compare your
376 automatic installation templates with the stock ones in
377 /var/lib/cobbler/autoinstall_templates if you have upgraded, to make
378 sure you can take advantage of all options to their fullest potential.
379 If you are a new cobbler user, base your automatic installation
380 templates off of these templates.
381 Read more about networking setup at:
383 https://github.com/cobbler/cobbler/wiki/Advanced-networking
384 cobbler system add --name=string --profile=string [--mac=macaddress]
386 [--ip-address=ipaddress] [--hostname=hostname] [--kopts=string]
387 [--ksmeta=string] [--autoinst=path] [--netboot-enabled=Y/N]
388 [--server=string] [--gateway=string] [--dns-name=string]
389 [--static-routes=string] [--power-address=string] [--power-type=string]
390 [--power-user=string] [--power-pass=string] [--power-id=string]
391 Adds a cobbler System to the configuration. Arguments are specified as
393 per "profile add" with the following changes:
394 name
396 The system name works like the name option for other commands.
397 If the name looks like a MAC address or an IP, the name will
399 implicitly be used for either --mac or --ip of the first interface,
400 respectively. However, it's usually better to give a descriptive
401 name -- don't rely on this behavior.
402 A system created with name "default" has special semantics. If a
404 default system object exists, it sets all undefined systems to PXE
405 to a specific profile. Without a "default" system name created,
406 PXE will fall through to local boot for unconfigured systems.
407 When using "default" name, don't specify any other arguments than
409 --profile ... they won't be used.
410 --mac
412 Specifying a mac address via --mac allows the system object to boot
413 directly to a specific profile via PXE, bypassing cobbler's PXE
414 menu. If the name of the cobbler system already looks like a mac
415 address, this is inferred from the system name and does not need to
416 be specified.
417 MAC addresses have the format AA:BB:CC:DD:EE:FF. It's highly
419 recommended to register your MAC-addresses in Cobbler if you're
420 using static addressing with multiple interfaces, or if you are
421 using any of the advanced networking features like bonding, bridges
422 or VLANs.
423 Cobbler does contain a feature (enabled in /etc/cobbler/settings)
425 that can automatically add new system records when it finds
426 profiles being provisioned on hardware it has seen before. This
427 may help if you do not have a report of all the MAC addresses in
428 your datacenter/lab configuration.
429 --ip-address
431 If cobbler is configured to generate a DHCP configuration (see
432 advanced section), use this setting to define a specific IP for
433 this system in DHCP. Leaving off this parameter will result in no
434 DHCP management for this particular system.
435 Example: --ip-address=192.168.1.50
437 If DHCP management is disabled and the interface is labelled
439 --static=1, this setting will be used for static IP configuration.
440 Special feature: To control the default PXE behavior for an entire
442 subnet, this field can also be passed in using CIDR notation. If
443 --ip is CIDR, do not specify any other arguments other than --name
444 and --profile.
445 When using the CIDR notation trick, don't specify any arguments
447 other than --name and --profile... they won't be used.
448 --dns-name
450 If using the DNS management feature (see advanced section --
451 cobbler supports auto-setup of BIND and dnsmasq), use this to
452 define a hostname for the system to receive from DNS.
453 Example: --dns-name=mycomputer.example.com
455 This is a per-interface parameter. If you have multiple
457 interfaces, it may be different for each interface, for example,
458 assume a DMZ / dual-homed setup.
459 --gateway and --netmask
461 If you are using static IP configurations and the interface is
462 flagged --static=1, these will be applied.
463 Netmask is a per-interface parameter. Because of the way gateway
465 is stored on the installed OS, gateway is a global parameter. You
466 may use --static-routes for per-interface customizations if
467 required.
468 --if-gateway
470 If you are using static IP configurations and have multiple
471 interfaces, use this to define different gateway for each
472 interface.
473 This is a per-interface setting.
475 --hostname
477 This field corresponds to the hostname set in a systems
478 /etc/sysconfig/network file. This has no bearing on DNS, even when
479 manage_dns is enabled. Use --dns-name instead for that feature.
480 This parameter is assigned once per system, it is not a per-
482 interface setting.
483 --power-address, --power-type, --power-user, --power-pass, --power-id
485 Cobbler contains features that enable integration with power
486 management for easier installation, reinstallation, and management
487 of machines in a datacenter environment. These parameters are
488 described online at
489 https://github.com/cobbler/cobbler/wiki/Power-management. If you
490 have a power-managed datacenter/lab setup, usage of these features
491 may be something you are interested in.
492 --static
494 Indicates that this interface is statically configured. Many
495 fields (such as gateway/netmask) will not be used unless this field
496 is enabled.
497 This is a per-interface setting.
499 --static-routes
501 This is a space delimited list of ip/mask:gateway routing
502 information in that format. Most systems will not need this
503 information.
504 This is a per-interface setting.
506 --virt-bridge
508 (Virt-only) While --virt-bridge is present in the profile object
509 (see above), here it works on an interface by interface basis.
510 For instance it would be possible to have --virt-bridge0=xenbr0 and
511 --virt-bridge1=xenbr1. If not specified in cobbler for each
512 interface, koan will use the value as specified in the profile for
513 each interface, which may not always be what is intended, but will
514 be sufficient in most cases.
515 This is a per-interface setting.
517 --autoinst
519 While it is recommended that the --autoinst parameter is only used
520 within for the "profile add" command, there are limited scenarios
521 when an install base switching to cobbler may have legacy automatic
522 installation files created on a per-system basis (one automatic
523 installation file for each system, nothing shared) and may not want
524 to immediately make use of the cobbler templating system. This
525 allows specifying a automatic installation file for use on a per-
526 system basis. Creation of a parent profile is still required. If
527 the automatic installation file is a filesystem location, it will
528 still be treated as a cobbler template.
529 --netboot-enabled
531 If set false, the system will be provisionable through koan but not
532 through standard PXE. This will allow the system to fall back to
533 default PXE boot behavior without deleting the cobbler system
534 object. The default value allows PXE. Cobbler contains a PXE
535 boot loop prevention feature (pxe_just_once, can be enabled in
536 /etc/cobbler/settings) that can automatically trip off this value
537 after a system gets done installing. This can prevent installs
538 from appearing in an endless loop when the system is set to PXE
539 first in the BIOS order.
540 --repos-enabled
542 If set true, koan can reconfigure repositories after installation.
543 This is described further on the Cobbler Wiki,
544 https://github.com/cobbler/cobbler/wiki/Manage-yum-repos.
545 --dhcp-tag
547 If you are setting up a PXE environment with multiple
548 subnets/gateways, and are using cobbler to manage a DHCP
549 configuration, you will probably want to use this option. If not,
550 it can be ignored.
551 By default, the dhcp tag for all systems is "default" and means
553 that in the DHCP template files the systems will expand out where
554 $insert_cobbler_systems_definitions is found in the DHCP template.
555 However, you may want certain systems to expand out in other places
556 in the DHCP config file. Setting --dhcp-tag=subnet2 for instance,
557 will cause that system to expand out where
558 $insert_cobbler_system_definitions_subnet2 is found, allowing you
559 to insert directives to specify different subnets (or other
560 parameters) before the DHCP configuration entries for those
561 particular systems.
562 This is described further on the Cobbler Wiki.
564 --interface
566 By default flags like --ip, --mac, --dhcp-tag, --dns-name,
567 --netmask, --virt-bridge, and --static-routes operate on the first
568 network interface defined for a system (eth0). However, cobbler
569 supports an arbitrary number of interfaces. Using --interface=eth1
570 for instance, will allow creating and editing of a second
571 interface.
572 Interface naming notes:
574 Additional interfaces can be specified (for example: eth1, or any
576 name you like, as long as it does not conflict with any reserved
577 names such as kernel module names) for use with the edit command.
578 Defining VLANs this way is also supported, of you want to add VLAN
579 5 on interface eth0, simply name your interface eth0.5.
580 Example:
582 cobbler system edit --name=foo --ip-address=192.168.1.50
584 --mac=AA:BB:CC:DD:EE:A0 cobbler system edit --name=foo
585 --interface=eth0 --ip-address=192.168.1.51 --mac=AA:BB:CC:DD:EE:A1
586 cobbler system report foo
587 Interfaces can be deleted using the --delete-interface option.
589 Example:
591 cobbler system edit --name=foo --interface=eth2 --delete-interface
593 --interface-type, --interface-master and --bonding-opts/--bridge-opts
595 One of the other advanced networking features supported by Cobbler
596 is NIC bonding, bridging, and BMC. You can use this to bond
597 multiple physical network interfaces to one single logical
598 interface to reduce single points of failure in your network, to
599 create bridged interfaces for things like tunnels and virtual
600 machine networks, or to manage BMC interface by DHCP. Supported
601 values for the --interface-type parameter are "bond", "bond_slave",
602 "bridge", "bridge_slave", "bonded_bridge_slave" and "bmc". If one
603 of the "_slave" options is specified, you also need to define the
604 master-interface for this bond using --interface-master=INTERFACE.
605 Bonding and bridge options for the master-interface may be
606 specified using --bonding-opts="foo=1 bar=2" or
607 --bridge-opts="foo=1 bar=2", respectively.
608 Example:
610 cobbler system edit --name=foo --interface=eth0
612 --mac=AA:BB:CC:DD:EE:00 --interface-type=bond_slave
613 --interface-master=bond0 cobbler system edit --name=foo
614 --interface=eth1 --mac=AA:BB:CC:DD:EE:01
615 --interface-type=bond_slave --interface-master=bond0 cobbler system
616 edit --name=foo --interface=bond0 --interface-type=bond
617 --bonding-opts="mode=active-backup miimon=100"
618 --ip-address=192.168.0.63 --netmask=255.255.255.0
619 --gateway=192.168.0.1 --static=1
620 More information about networking setup is available at
622 https://github.com/cobbler/cobbler/wiki/Advanced-networking
623 To review what networking configuration you have for any object,
625 run "cobbler system report" at any time:
626 Example:
628 cobbler system report --name=foo
630 REPOSITORIES
632 Repository mirroring allows cobbler to mirror not only install trees
633 ("cobbler import" does this for you) but also optional packages, 3rd
634 party content, and even updates. Mirroring all of this content
635 locally on your network will result in faster, more up-to-date
636 installations and faster updates. If you are only provisioning a home
637 setup, this will probably be overkill, though it can be very useful for
638 larger setups (labs, datacenters, etc).
639 cobbler repo add --mirror=url --name=string [--rpmlist=list]
641 [--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number]
642 [--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn]
643 mirror
645 The address of the yum mirror. This can be an rsync:// URL, an ssh
646 location, or a http:// or ftp:// mirror location. Filesystem paths
647 also work.
648 The mirror address should specify an exact repository to mirror --
650 just one architecture and just one distribution. If you have a
651 separate repo to mirror for a different arch, add that repo
652 separately.
653 Here's an example of what looks like a good URL:
655 rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386
657 (for rsync protocol)
658 http://mirrors.kernel.org/fedora/extras/6/i386/ (for http://)
659 user@yourmirror.example.com/fedora-linux-core/updates/6/i386 (for
660 SSH)
661 Experimental support is also provided for mirroring RHN content
663 when you need a fast local mirror. The mirror syntax for this is
664 --mirror=rhn://channel-name and you must have entitlements for this
665 to work. This requires the cobbler server to be installed on RHEL5
666 or later. You will also need a version of yum-utils equal or
667 greater to 1.0.4.
668 name
670 This name is used as the save location for the mirror. If the
671 mirror represented, say, Fedora Core 6 i386 updates, a good name
672 would be "fc6i386updates". Again, be specific.
673 This name corresponds with values given to the --repos parameter of
675 "cobbler profile add". If a profile has a --repos value that
676 matches the name given here, that repo can be automatically set up
677 during provisioning (when supported) and installed systems will
678 also use the boot server as a mirror (unless
679 "yum_post_install_mirror" is disabled in the settings file). By
680 default the provisioning server will act as a mirror to systems it
681 installs, which may not be desirable for laptop configurations,
682 etc.
683 Distros that can make use of yum repositories during automatic
685 installation include FC6 and later, RHEL 5 and later, and
686 derivative distributions.
687 See the documentation on "cobbler profile add" for more
689 information.
690 rpm-list
692 By specifying a space-delimited list of package names for
693 --rpm-list, one can decide to mirror only a part of a repo (the
694 list of packages given, plus dependencies). This may be helpful in
695 conserving time/space/bandwidth. For instance, when mirroring FC6
696 Extras, it may be desired to mirror just cobbler and koan, and skip
697 all of the game packages. To do this, use --rpm-list="cobbler
698 koan".
699 This option only works for http:// and ftp:// repositories (as it
701 is powered by yumdownloader). It will be ignored for other mirror
702 types, such as local paths and rsync:// mirrors.
703 createrepo-flags
705 Specifies optional flags to feed into the createrepo tool, which is
706 called when "cobbler reposync" is run for the given repository.
707 The defaults are '-c cache'.
708 keep-updated
710 Specifies that the named repository should not be updated during a
711 normal "cobbler reposync". The repo may still be updated by
712 name. The repo should be synced at least once before disabling
713 this feature See "cobbler reposync" below.
714 mirror-locally
716 When set to "N", specifies that this yum repo is to be referenced
717 directly via automatic installation files and not mirrored locally
718 on the cobbler server. Only http:// and ftp:// mirror urls are
719 supported when using --mirror-locally=N, you cannot use filesystem
720 URLs.
721 priority
723 Specifies the priority of the repository (the lower the number, the
724 higher the priority), which applies to installed machines using the
725 repositories that also have the yum priorities plugin installed.
726 The default priority for the plugin is 99, as is that of all
727 cobbler mirrored repositories.
728 arch
730 Specifies what architecture the repository should use. By default
731 the current system arch (of the server) is used, which may not be
732 desirable. Using this to override the default arch allows
733 mirroring of source repositories (using --arch=src).
734 yumopts
736 Sets values for additional yum options that the repo should use on
737 installed systems. For instance if a yum plugin takes a certain
738 parameter "alpha" and "beta", use something like --yumopts="alpha=2
739 beta=3".
740 breed
742 Ordinarily cobbler's repo system will understand what you mean
743 without supplying this parameter, though you can set it explicitly
744 if needed.
745 MANAGEMENT CLASSES
747 Management classes allows cobbler to function as an configuration
748 management system. Cobbler currently supports the following resource
749 types:
750 1. Packages
752 2. Files
753 Resources are executed in the order listed above.
755 cobbler mgmtclass add --name=string --comment=string [--packages=list]
757 [--files=list]
758 name
760 The name of the mgmtclass. Use this name when adding a management
761 class to a system, profile, or distro. To add a mgmtclass to an
762 existing system use something like (cobbler system edit
763 --name="madhatter" --mgmt-classes="http mysql").
764 comment
766 A comment that describes the functions of the management class.
767 packages
769 Specifies a list of package resources required by the management
770 class.
771 files
773 Specifies a list of file resources required by the management
774 class.
775
777 Resources are the lego blocks of configuration management. Resources
778 are grouped together via Management Classes, which are then linked to a
779 system. Cobbler supports two (2) resource types. Resources are
780 configured in the order listed below.
781 1. Packages
783 2. Files
784 PACKAGE RESOURCES
786 Package resources are managed using cobbler package add
787 Actions
789 install
791 Install the package. [Default]
792 uninstall
794 Uninstall the package.
795 Attributes
797 installer
799 Which package manager to use, vaild options [rpm|yum].
800 version
802 Which version of the package to install.
803 Examples
805 cobbler package add --name=string --comment=string
807 [--action=install|uninstall] --installer=string [--version=string]
808 FILE RESOURCES
810 Actions
811 create
813 Create the file. [Default]
814 remove
816 Remove the file.
817 Attributes
819 mode
821 Permission mode (as in chmod).
822 group
824 The group owner of the file.
825 user
827 The user for the file.
828 path
830 The path for the file.
831 template
833 The template for the file.
834 Examples
836 cobbler file add --name=string --comment=string [--action=string]
838 --mode=string --group=string --owner=string --path=string
839 [--template=string]
840 DISPLAYING CONFIGURATION ENTRIES
842 The following commands are usable regardless of how you are using
843 cobbler. "report" gives detailed configuration info. "list" just lists
844 the names of items in the configuration. Run these commands to check
845 how you have cobbler configured.
846 cobbler list
848 cobbler distro|profile|system|repo|image|mgmtclass|package|file list
850 cobbler report
852 cobbler distro|profile|system|repo|image|mgmtclass|package|file report
854 --name=[object-name]
855 Alternatively, you could look at the configuration files in
857 /var/lib/cobbler to see the same information.
858 DELETING CONFIGURATION ENTRIES
860 If you want to remove a specific object, use the remove command with
861 the name that was used to add it.
862 cobbler distro remove --name=string
864 cobbler profile remove --name=string
866 cobbler system remove --name=string
868 cobbler repo remove --name=string
870 cobbler image remove --name=string
872 cobbler mgmtclass remove --name=string
874 cobbler package remove --name=string
876 cobbler file remove --name=string
878 EDITING
880 If you want to change a particular setting without doing an "add"
881 again, use the "edit" command, using the same name you gave when you
882 added the item. Anything supplied in the parameter list will overwrite
883 the settings in the existing object, preserving settings not mentioned.
884 cobbler distro|profile|system|repo|image|mgmtclass|package|file edit
886 --name=string [parameterlist]
887 COPYING
889 Objects can also be copied:
890 cobbler distro|profile|system|repo|image|mgmtclass|package|file copy
892 --name=oldname --newname=newname
893 RENAMING
895 Objects can also be renamed, as long as other objects don't reference
896 them.
897 cobbler distro|profile|system|repo|image|mgmtclass|package|file rename
899 --name=oldname --newname=newname
900 REPLICATING
902 Cobbler can replicate configurations from a master cobbler server.
903 Each cobbler server is still expected to have a locally relevant
904 /etc/cobbler/cobbler.conf and modules.conf, as these files are not
905 synced.
906 This feature is intended for load-balancing, disaster-recovery, backup,
908 or multiple geography support.
909 cobbler replicate --master=cobbler.example.org [--distros=pattern]
911 [--profiles=pattern] [--systems=pattern] [--repos-pattern]
912 [--images=pattern] [--prune] [--omit-data]
913 Cobbler can replicate data from a central server.
915 Objects that need to be replicated should be specified with a pattern,
917 such as --profiles="webservers* dbservers*" or
918 --systems="*.example.org". All objects matched by the pattern, and
919 all dependencies of those objects matched by the pattern (recursively)
920 will be transferred from the remote server to the central server. This
921 is to say if you intend to transfer "*.example.org" and the definition
922 of the systems have not changed, but a profile above them has changed,
923 the changes to that profile will also be transferred.
924 In the case where objects are more recent on the local server, those
926 changes will not be overridden locally.
927 Common data locations will be rsync'ed from the master server unless
929 --omit-data is specified.
930 To delete objects that are no longer present on the master server, use
932 --prune. Warning: this will delete all object types not present on
933 the remote server from the local server, and is recursive. If you use
934 prune, it is best to manage cobbler centrally and not expect changes
935 made on the slave servers to be preserved. It is not currently
936 possible to just prune objects of a specific type.
937 REBUILDING CONFIGURATIONS
939 cobbler sync
940 Cobbler sync is used to repair or rebuild the contents /tftpboot or
942 /var/www/cobbler when something has changed behind the scenes. It
943 brings the filesystem up to date with the configuration as understood
944 by cobbler.
945 Sync should be run whenever files in /var/lib/cobbler are manually
947 edited (which is not recommended except for the settings file) or when
948 making changes to automatic installation files. In practice, this
949 should not happen often, though running sync too many times does not
950 cause any adverse effects.
951 If using cobbler to manage a DHCP and/or DNS server (see the advanced
953 section of this manpage), sync does need to be run after systems are
954 added to regenerate and reload the DHCP/DNS configurations.
955 The sync process can also be kicked off from the web interface.
957
959 IMPORT WORKFLOW
960 Import is a very useful command that makes starting out with cobbler
961 very quick and easy.
962 This example shows how to create a provisioning infrastructure from a
964 distribution mirror or DVD ISO. Then a default PXE configuration is
965 created, so that by default systems will PXE boot into a fully
966 automated install process for that distribution.
967 You can use a network rsync mirror, a mounted DVD location, or a tree
969 you have available via a network filesystem.
970 Import knows how to autodetect the architecture of what is being
972 imported, though to make sure things are named correctly, it's always a
973 good idea to specify --arch. For instance, if you import a
974 distribution named "fedora8" from an ISO, and it's an x86_64 ISO,
975 specify --arch=x86_64 and the distro will be named "fedora8-x86_64"
976 automatically, and the right architecture field will also be set on the
977 distribution object. If you are batch importing an entire mirror
978 (containing multiple distributions and arches), you don't have to do
979 this, as cobbler will set the names for things based on the paths it
980 finds.
981 cobbler check
983 cobbler import --path=rsync://yourfavoritemirror.com/rhel/5/os/x86_64
985 --name=rhel5 --arch=x86_64
986 # OR
988 cobbler import --path=/mnt/dvd --name=rhel5 --arch=x86_64
990 # OR (using an external NAS box without mirroring)
992 cobbler import --path=/path/where/filer/is/mounted --name=anyname
994 --available-as=nfs://nfs.example.org:/where/mounted/
995 # wait for mirror to rsync...
997 cobbler report
999 cobbler system add --name=default --profile=name_of_a_profile1
1001 cobbler system add --name=AA:BB:CC:DD:EE:FF
1003 --profile=name_of_a_profile2
1004 cobbler sync
1006 NON-IMPORT (MANUAL) WORKFLOW
1008 The following example uses a local kernel and initrd file (already
1009 downloaded), and shows how profiles would be created using two
1010 different automatic installation files -- one for a web server
1011 configuration and one for a database server. Then, a machine is
1012 assigned to each profile.
1013 cobbler check
1015 cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz
1017 --initrd=/dir1/initrd.img
1018 cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz
1020 --initrd=/dir2/initrd.img
1021 cobbler profile add --name=fc5webservers --distro=fc5-i386
1023 --autoinst=/dir4/kick.ks --kopts="something_to_make_my_gfx_card_work=42
1024 some_other_parameter=foo"
1025 cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3
1027 --autoinst=/dir5/kick.ks
1028 cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
1030 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
1032 cobbler report
1034 REPOSITORY MIRRORING WORKFLOW
1036 The following example shows how to set up a repo mirror for two
1037 repositories, and create a profile that will auto install those
1038 repository configurations on provisioned systems using that profile.
1039 cobbler check
1041 # set up your cobbler distros here.
1043 cobbler repo add
1045 --mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/
1046 --name=fc6i386updates
1047 cobbler repo add
1049 --mirror=http://mirrors.kernel.org/fedora/extras/6/i386/
1050 --name=fc6i386extras
1051 cobbler reposync
1053 cobbler profile add --name=p1 --distro=existing_distro_name
1055 --autoinst=/etc/cobbler/kickstart_fc6.ks --repos="fc6i386updates
1056 fc6i386extras"
1057 VIRTUALIZATION
1059 For Virt, be sure the distro uses the correct kernel (if paravirt) and
1060 follow similar steps as above, adding additional parameters as desired:
1061 cobbler distro add --name=fc7virt [options...]
1063 Specify reasonable values for the Virt image size (in GB) and RAM
1065 requirements (in MB):
1066 cobbler profile add --name=virtwebservers --distro=fc7virt
1068 --autoinst=path --virt-file-size=10 --virt-ram=512 [...]
1069 Define systems if desired. koan can also provision based on the
1071 profile name.
1072 cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers
1074 [...]
1075 If you have just installed cobbler, be sure that the "cobblerd" service
1077 is running and that port 25151 is unblocked.
1078 See the manpage for koan for the client side steps.
1080
1082 PXE MENUS
1083 Cobbler will automatically generate PXE menus for all profiles it has
1084 defined. Running "cobbler sync" is required to generate and update
1085 these menus.
1086 To access the menus, type "menu" at the "boot:" prompt while a system
1088 is PXE booting. If nothing is typed, the network boot will default to
1089 a local boot. If "menu" is typed, the user can then choose and
1090 provision any cobbler profile the system knows about.
1091 If the association between a system (MAC address) and a profile is
1093 already known, it may be more useful to just use "system add" commands
1094 and declare that relationship in cobbler; however many use cases will
1095 prefer having a PXE system, especially when provisioning is done at the
1096 same time as installing new physical machines.
1097 If this behavior is not desired, run "cobbler system add --name=default
1099 --profile=plugh" to default all PXE booting machines to get a new copy
1100 of the profile "plugh". To go back to the menu system, run "cobbler
1101 system remove --name=default" and then "cobbler sync" to regenerate the
1102 menus.
1103 When using PXE menu deployment exclusively, it is not necessary to make
1105 cobbler system records, although the two can easily be mixed.
1106 Additionally, note that all files generated for the pxe menu
1108 configurations are templatable, so if you wish to change the color
1109 scheme or equivalent, see the files in /etc/cobbler.
1110 AUTOMATIC INSTALLATION TEMPLATING
1112 The --autoinstall_meta options above require more explanation.
1113 If and only if --autoinst options reference filesystem URLs, --ksmeta
1115 allows for templating of the automatic installation files to achieve
1116 advanced functions. If the --ksmeta option for a profile read
1117 --ksmeta="foo=7 bar=llama", anywhere in the automatic installation file
1118 where the string "$bar" appeared would be replaced with the string
1119 "llama".
1120 To apply these changes, "cobbler sync" must be run to generate custom
1122 automatic installation files for each profile/system.
1123 For NFS and HTTP automatic installation file URLs, the
1125 "--autoinstall_meta" options will have no effect. This is a good reason
1126 to let cobbler manage your automatic installation files, though the URL
1127 functionality is provided for integration with legacy infrastructure,
1128 possibly including web apps that already generate automatic
1129 installation files.
1130 Templated automatic files are processed by the templating
1132 program/package Cheetah, so anything you can do in a Cheetah template
1133 can be done to an automatic installation template. Learn more at
1134 http://www.cheetahtemplate.org/learn.html
1135 When working with Cheetah, be sure to escape any shell macros that look
1137 like "$(this)" with something like "\$(this)" or errors may show up
1138 during the sync process.
1139 The Cobbler Wiki also contains numerous Cheetah examples that should
1141 prove useful in using this feature.
1142 AUTOMATIC INSTALLATION SNIPPETS
1144 Anywhere a automatic installation template mentions
1145 SNIPPET::snippet_name, the file named
1146 /var/lib/cobbler/snippets/snippet_name (if present) will be included
1147 automatically in the automatic installation template. This serves as a
1148 way to recycle frequently used automatic installation snippets without
1149 duplication. Snippets can contain templating variables, and the
1150 variables will be evaluated according to the profile and/or system as
1151 one would expect.
1152 Snippets can also be overridden for specific profile names or system
1154 names. This is described on the Cobbler Wiki.
1155 KICKSTART VALIDATION
1157 To check for potential errors in kickstarts, prior to installation, use
1158 "cobbler validateks". This function will check all profile and system
1159 kickstarts for detectable errors. Since pykickstart is not future-
1160 Anaconda-version aware, there may be some false positives. It should
1161 be noted that "cobbler validateks" runs on the rendered kickstart
1162 output, not kickstart templates themselves.
1163 DHCP MANAGEMENT
1165 Cobbler can optionally help you manage DHCP server. This feature is
1166 off by default.
1167 Choose either "management = isc_and_bind" in /etc/cobbler/dhcp.template
1169 or "management = "dnsmasq" in /etc/cobbler/modules.conf. Then set
1170 "manage_dhcp" to 1 in /etc/cobbler/settings.
1171 This allows DHCP to be managed via "cobbler system add" commands, when
1173 you specify the mac address and IP address for systems you add into
1174 cobbler.
1175 Depending on your choice, cobbler will use /etc/cobbler/dhcpd.template
1177 or /etc/cobbler/dnsmasq.template as a starting point. This file must
1178 be user edited for the user's particular networking environment. Read
1179 the file and understand how the particular app (ISC dhcpd or dnsmasq)
1180 work before proceeding.
1181 If you already have DHCP configuration data that you would like to
1183 preserve (say DHCP was manually configured earlier), insert the
1184 relevant portions of it into the template file, as running "cobbler
1185 sync" will overwrite your previous configuration.
1186 By default, the DHCP configuration file will be updated each time
1188 "cobbler sync" is run, and not until then, so it is important to
1189 remember to use "cobbler sync" when using this feature.
1190 If omapi_enabled is set to 1 in /etc/cobbler/settings, the need to sync
1192 when adding new system records can be eliminated. However, the omapi
1193 feature is experimental and is not recommended for most users.
1194 DNS CONFIGURATION MANAGEMENT
1196 Cobbler can optionally manage DNS configuration using BIND and dnsmasq.
1197 Choose either "management = isc_and_bind" or "management = dnsmasq" in
1199 /etc/cobbler/modules.conf and then enable manage_dns in
1200 /etc/cobbler/settings.
1201 This feature is off by default. If using BIND, you must define the
1203 zones to be managed with the options 'manage_forward_zones' and
1204 'manage_reverse_zones'. (See the Wiki for more information on this).
1205 If using BIND, Cobbler will use /etc/cobbler/named.template and
1207 /etc/cobbler/zone.template as a starting point for the named.conf and
1208 individual zone files, respectively. You may drop zone-specific
1209 template files in /etc/cobbler/zone_templates/name-of-zone which will
1210 override the default. These files must be user edited for the user's
1211 particular networking environment. Read the file and understand how
1212 BIND works before proceeding.
1213 If using dnsmasq, the template is /etc/cobbler/dnsmasq.template. Read
1215 this file and understand how dnsmasq works before proceeding.
1216 All managed files (whether zone files and named.conf for BIND, or
1218 dnsmasq.conf for dnsmasq) will be updated each time ``cobbler sync'' is
1219 run, and not until then, so it is important to remember to use
1220 ``cobbler sync'' when using this feature.
1221 IMPORTING TREES
1223 Cobbler can auto-add distributions and profiles from remote sources,
1224 whether this is a filesystem path or an rsync mirror. This can save a
1225 lot of time when setting up a new provisioning environment. Import is
1226 a feature that many users will want to take advantage of, and is very
1227 simple to use.
1228 After an import is run, cobbler will try to detect the distribution
1230 type and automatically assign automatic installation files. By
1231 default, it will provision the system by erasing the hard drive,
1232 setting up eth0 for dhcp, and using a default password of "cobbler".
1233 If this is undesirable, edit the automatic installation files in
1234 /etc/cobbler to do something else or change the automatic installation
1235 setting after cobbler creates the profile.
1236 Mirrored content is saved automatically in
1238 /var/www/cobbler/distro_mirror.
1239 Example: cobbler import --path=rsync://mirrorserver.example.com/path/
1241 --name=fedora --arch=x86
1242 Example2: cobbler import --path=root@192.168.1.10:/stuff --name=bar
1244 Example3: cobbler import --path=/mnt/dvd --name=baz --arch=x86_64
1246 Example4: cobbler import --path=/path/to/stuff --name=glorp
1248 Example5: cobbler import --path=/path/where/filer/is/mounted
1250 --name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
1251 Once imported, run a "cobbler list" or "cobbler report" to see what
1253 you've added.
1254 By default, the rsync operations will exclude content of certain
1256 architectures, debug RPMs, and ISO images -- to change what is excluded
1257 during an import, see /etc/cobbler/rsync.exclude.
1258 Note that all of the import commands will mirror install tree content
1260 into /var/www/cobbler unless a network accessible location is given
1261 with --available-as. --available-as will be primarily used when
1262 importing distros stored on an external NAS box, or potentially on
1263 another partition on the same machine that is already accessible via
1264 http:// or ftp://.
1265 For import methods using rsync, additional flags can be passed to rsync
1267 with the option --rsync-flags.
1268 Should you want to force the usage of a specific cobbler automatic
1270 installation template for all profiles created by an import, you can
1271 feed the option --autoinst to import, to bypass the built-in automatic
1272 installation file auto-detection.
1273 DEFAULT PXE BOOT BEHAVIOR
1275 What happens when PXE booting a system when cobbler has no record of
1276 the system being booted?
1277 By default, cobbler will configure PXE to boot to the contents of
1279 /etc/cobbler/default.pxe, which (if unmodified) will just fall through
1280 to the local boot process. Administrators can modify this file if they
1281 like to change that behavior.
1282 An easy way to specify a default cobbler profile to PXE boot is to
1284 create a system named "default". This will cause
1285 /etc/cobbler/default.pxe to be ignored. To restore the previous
1286 behavior do a "cobbler system remove" on the "default" system.
1287 cobbler system add --name=default --profile=boot_this
1289 cobbler system remove --name=default
1291 As mentioned in earlier sections, it is also possible to control the
1293 default behavior for a specific network:
1294 cobbler system add --name=network1 --ip-address=192.168.0.0/24
1296 --profile=boot_this
1297 REPO MANAGEMENT
1299 This has already been covered a good bit in the command reference
1300 section.
1301 Yum repository management is an optional feature, and is not required
1303 to provision through cobbler. However, if cobbler is configured to
1304 mirror certain repositories, it can then be used to associate profiles
1305 with those repositories. Systems installed under those profiles will
1306 then be autoconfigured to use these repository mirrors in
1307 /etc/yum.repos.d, and if supported (Fedora Core 6 and later) these
1308 repositories can be leveraged even within Anaconda. This can be useful
1309 if (A) you have a large install base, (B) you want fast installation
1310 and upgrades for your systems, or (C) have some extra software not in a
1311 standard repository but want provisioned systems to know about that
1312 repository.
1313 Make sure there is plenty of space in cobbler's webdir, which defaults
1315 to /var/www/cobbler.
1316 cobbler reposync [--tries=N] [--no-fail]
1318 Cobbler reposync is the command to use to update repos as configured
1320 with "cobbler repo add". Mirroring can take a long time, and usage of
1321 cobbler reposync prior to usage is needed to ensure provisioned systems
1322 have the files they need to actually use the mirrored repositories. If
1323 you just add repos and never run "cobbler reposync", the repos will
1324 never be mirrored. This is probably a command you would want to put on
1325 a crontab, though the frequency of that crontab and where the output
1326 goes is left up to the systems administrator.
1327 For those familiar with yum's reposync, cobbler's reposync is (in most
1329 uses) a wrapper around the yum command. Please use "cobbler reposync"
1330 to update cobbler mirrors, as yum's reposync does not perform all
1331 required steps. Also cobbler adds support for rsync and SSH locations,
1332 where as yum's reposync only supports what yum supports (http/ftp).
1333 If you ever want to update a certain repository you can run:
1335 cobbler reposync --only="reponame1" ...
1337 When updating repos by name, a repo will be updated even if it is set
1339 to be not updated during a regular reposync operation (ex: cobbler repo
1340 edit --name=reponame1 --keep-updated=0).
1341 Note that if a cobbler import provides enough information to use the
1343 boot server as a yum mirror for core packages, cobbler can set up
1344 automatic installation files to use the cobbler server as a mirror
1345 instead of the outside world. If this feature is desirable, it can be
1346 turned on by setting yum_post_install_mirror to 1 in /etc/settings
1347 ((and running "cobbler sync"). You should not use this feature if
1348 machines are provisioned on a different VLAN/network than production,
1349 or if you are provisioning laptops that will want to acquire updates on
1350 multiple networks.
1351 The flags --tries=N (for example, --tries=3) and --no-fail should
1353 likely be used when putting reposync on a crontab. They ensure network
1354 glitches in one repo can be retried and also that a failure to
1355 synchronize one repo does not stop other repositories from being
1356 synchronized.
1357 PXE BOOT LOOP PREVENTION
1359 If you have your machines set to PXE first in the boot order (ahead of
1360 hard drives), change the "pxe_just_once" flag in /etc/cobbler/settings
1361 to 1. This will set the machines to not PXE on successive boots once
1362 they complete one install. To re-enable PXE for a specific system, run
1363 the following command:
1364 cobbler system edit --name=name --netboot-enabled=1
1366 AUTOMATIC INSTALLATION TRACKING
1368 Cobbler knows how to keep track of the status of automatic installation
1369 of machines.
1370 cobbler status
1372 Using the status command will show when cobbler thinks a machine
1374 started automatic installation and when it finished, provided the
1375 proper snippets are found in the automatic installation template.
1376 This is a good way to track machines that may have gone interactive (or
1377 stalled/crashed) during automatic installation.
1378 IMAGES
1380 Cobbler can help with booting images physically and virtually, though
1381 the usage of these commands varies substantially by the type of image.
1382 Non-image based deployments are generally easier to work with and lead
1383 to more sustaintable infrastructure. Some manual use of other commands
1384 beyond of what is typically required of cobbler may be needed to
1385 prepare images for use with this feature.
1386 TRIGGERS
1388 Triggers provide a way to integrate cobbler with arbitrary 3rd party
1389 software without modifying cobbler's code. When adding a distro,
1390 profile, system, or repo, all scripts in /var/lib/cobbler/triggers/add
1391 are executed for the particular object type. Each particular file must
1392 be executable and it is executed with the name of the item being added
1393 as a parameter. Deletions work similarly -- delete triggers live in
1394 /var/lib/cobbler/triggers/delete. Order of execution is arbitrary, and
1395 cobbler does not ship with any triggers by default. There are also
1396 other kinds of triggers -- these are described on the Cobbler Wiki.
1397 For larger configurations, triggers should be written in Python -- in
1398 which case they are installed differently. This is also documented on
1399 the Wiki.
1400 API
1402 Cobbler also makes itself available as an XMLRPC API for use by higher
1403 level management software. Learn more at https://cobbler.github.io
1404 WEB USER INTERFACE
1406 Most of the day-to-day actions in cobbler's command line can be
1407 performed in Cobbler's Web UI. To enable and access the WebUI, see the
1408 following documentation:
1409 https://github.com/cobbler/cobbler/wiki/Cobbler-web-interface
1411 BOOT CD
1413 Cobbler can build all of it's profiles into a bootable CD image using
1414 the "cobbler buildiso" command. This allows for PXE-menu like bringup
1415 of bare metal in environments where PXE is not possible. Another more
1416 advanced method is described in the koan manpage, though this method is
1417 easier and sufficient for most applications.
1418 POWER MANAGEMENT
1420 Cobbler contains a power management feature that allows the user to
1421 associate system records in cobbler with the power management
1422 configuration attached to them. This can ease installation by making
1423 it easy to reassign systems to new operating systems and then reboot
1424 those systems. Read more about this feature at
1425 https://github.com/cobbler/cobbler/wiki/Power-management
1426 CONFIG MANAGEMENT INTEGRATION
1428 Cobbler contains features for integrating an installation environment
1429 with a configuration management system, which handles the configuration
1430 of the system after it is installed by allowing changes to
1431 configuration files and settings. You can read more about this feature
1432 at
1433 https://github.com/cobbler/cobbler/wiki/Built-in-configuration-management
1434 and
1435 https://github.com/cobbler/cobbler/wiki/Using-cobbler-with-a-configuration-management-system.
1436 Both features may be considered experimental as of time of the 1.4
1437 release.
1438
1440 cobbler's command line returns a zero for success and non-zero for
1441 failure.
1442
1444 Cobbler has a mailing list for user and development-related
1445 questions/comments at cobbler@lists.fedorahosted.org. To subscribe,
1446 visit https://fedorahosted.org/mailman/listinfo/cobbler
1447 IRC channel: irc.freenode.net (#cobbler)
1449 Official web site, bug tracker, and Wiki: https://cobbler.github.io
1451
1453 Michael DeHaan <michael.dehaan AT gmail>
14542.9.0 2019-10-22 COBBLER.1(1)