cobbler - Man Page

Cobbler has a system of inheritance when it comes to managing the information you want to apply to a certain system.

If you want to remove a specific object, use the remove command with the name that was used to add it.

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu remove --name=string

If you want to change a particular setting without doing an add again, use the edit command, using the same name you gave when you added the item. Anything supplied in the parameter list will overwrite the settings in the existing object, preserving settings not mentioned.

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu edit --name=string [parameterlist]

Objects can also be copied:

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu copy --name=oldname --newname=newname

Objects can also be renamed, as long as other objects don't reference them.

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu rename --name=oldname --newname=newname

This first step towards configuring what you want to install is to add a distribution record to Cobbler's configuration.

If there is an rsync mirror, DVD, NFS, or filesystem tree available that you would rather import instead, skip down to the documentation about the import command. It's really a lot easier to follow the import workflow -- it only requires waiting for the mirror content to be copied and/or scanned. Imported mirrors also save time during install since they don't have to hit external install sources.

If you want to be explicit with distribution definition, however, here's how it works:

$ cobbler distro add --name=string --kernel=path --initrd=path [--kernel-options=string] [--kernel-options-post=string] [--autoinstall-meta=string] [--arch=i386|x86_64|ppc|ppc64|ppc64le|arm64] [--breed=redhat|debian|suse] [--template-files=string]

A profile associates a distribution to additional specialized options, such as a installation automation file. Profiles are the core unit of provisioning and at least one profile must exist for every distribution to be provisioned. A profile might represent, for instance, a web server or desktop configuration. In this way, profiles define a role to be performed.

$ cobbler profile add --name=string --distro=string [--autoinstall=path] [--kernel-options=string] [--autoinstall-meta=string] [--name-servers=string] [--name-servers-search=string] [--virt-file-size=gigabytes] [--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer] [--virt-path=string] [--virt-bridge=string] [--server] [--parent=profile] [--filename=string]

Arguments are the same as listed for distributions, save for the removal of "arch" and "breed", and with the additions listed below:

System records map a piece of hardware (or a virtual machine) with the Cobbler profile to be assigned to run on it. This may be thought of as choosing a role for a specific system.

Note that if provisioning via Koan and PXE menus alone, it is not required to create system records in Cobbler, though they are useful when system specific customizations are required. One such customization would be defining the MAC address. If there is a specific role intended for a given machine, system records should be created for it.

System commands have a wider variety of control offered over network details. In order to use these to the fullest possible extent, the automatic installation template used by Cobbler must contain certain automatic installation snippets (sections of code specifically written for Cobbler to make these values become reality). Compare your automatic installation templates with the stock ones in /var/lib/cobbler/templates if you have upgraded, to make sure you can take advantage of all options to their fullest potential. If you are a new Cobbler user, base your automatic installation templates off of these templates.

Read more about networking setup at: https://cobbler.readthedocs.io/en/release28/4_advanced/advanced%20networking.html

Example:

$ cobbler system add --name=string --profile=string [--mac=macaddress] [--ip-address=ipaddress] [--hostname=hostname] [--kernel-options=string] [--autoinstall-meta=string] [--autoinstall=path] [--netboot-enabled=Y/N] [--server=string] [--gateway=string] [--dns-name=string] [--static-routes=string] [--power-address=string] [--power-type=string] [--power-user=string] [--power-pass=string] [--power-id=string]

Adds a Cobbler System to the configuration. Arguments are specified as per "profile add" with the following changes:

Repository mirroring allows Cobbler to mirror not only install trees ("cobbler import" does this for you) but also optional packages, 3rd party content, and even updates. Mirroring all of this content locally on your network will result in faster, more up-to-date installations and faster updates. If you are only provisioning a home setup, this will probably be overkill, though it can be very useful for larger setups (labs, datacenters, etc).

$ cobbler repo add --mirror=url --name=string [--rpmlist=list] [--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number] [--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn] [--mirror_type=baseurl|mirrorlist|metalink]

$ cobbler repo autoadd

Add enabled yum repositories from dnf repolist --enabled list. The repository names are generated using the <repo id>-<releasever>-<arch> pattern (ex: fedora-32-x86_64). Existing repositories with such names are not overwritten.

Example:

$ cobbler image

Management classes allows Cobbler to function as an configuration management system. Cobbler currently supports the following resource types:

1. Packages
2. Files

Resources are executed in the order listed above.

$ cobbler mgmtclass add --name=string --comment=string [--packages=list] [--files=list]

Package resources are managed using cobbler package add

Actions:

Attributes:

Example:

$ cobbler package add --name=string --comment=string [--action=install|uninstall] --installer=string [--version=string]

Actions:

Attributes:

Example:

$ cobbler file add --name=string --comment=string [--action=string] --mode=string --group=string --owner=string --path=string [--template=string]

By default, Cobbler builds a single-level boot menu for profiles and images. To simplify navigation through a large number of OS boot items, you can create menu objects and place any number of submenus, profiles, and images there. The menu is hierarchical, to indicate the nesting of one submenu in another, you can use the parent property. If the parent property for a submenu, or the menu property for a profile or images are not set or have an empty value, then the corresponding element will be displayed in the top-level menu. If a submenu does not have descendants in the form of profiles or images, then such a submenu will not be displayed in the boot menu.

$ cobbler menu add --name=string [--display-name=string] [--parent=string]

Example:

$ cobbler aclsetup

This command may not behave like you expect it without installing additional dependencies and configuration. The in depth explanation can be found at Building ISOs.

NOTE:

Example: The following command builds a single ISO file for all profiles and systems present under the distro test.

$ cobbler buildiso --distro=test

NOTE:

When running Cobbler via systemd, you cannot mount the ISO to /tmp or a sub-folder of it because we are using the option Private Temporary Directory, to enhance the security of our application.

Example:

$ cobbler import

This list all the names grouped by type. Identically to cobbler report there are subcommands for most of the other Cobbler commands. (Currently: distro, profile, system, repo, image, mgmtclass, package, file)

$ cobbler list

Cobbler can replicate configurations from a master Cobbler server. Each Cobbler server is still expected to have a locally relevant /etc/cobbler/cobbler.conf and modules.conf, as these files are not synced.

This feature is intended for load-balancing, disaster-recovery, backup, or multiple geography support.

Cobbler can replicate data from a central server.

Objects that need to be replicated should be specified with a pattern, such as --profiles="webservers* dbservers*" or --systems="*.example.org". All objects matched by the pattern, and all dependencies of those objects matched by the pattern (recursively) will be transferred from the remote server to the central server. This is to say if you intend to transfer *.example.org and the definition of the systems have not changed, but a profile above them has changed, the changes to that profile will also be transferred.

In the case where objects are more recent on the local server, those changes will not be overridden locally.

Common data locations will be rsync'ed from the master server unless --omit-data is specified.

To delete objects that are no longer present on the master server, use --prune.

Warning: This will delete all object types not present on the remote server from the local server, and is recursive. If you use prune, it is best to manage Cobbler centrally and not expect changes made on the slave servers to be preserved. It is not currently possible to just prune objects of a specific type.

Example:

$ cobbler replicate --master=cobbler.example.org [--distros=pattern] [--profiles=pattern] [--systems=pattern] [--repos-pattern] [--images=pattern] [--prune] [--omit-data]

This lists all configuration which Cobbler can obtain from the saved data. There are also report subcommands for most of the other Cobbler commands (currently: distro, profile, system, repo, image, mgmtclass, package, file, menu).

$ cobbler report --name=[object-name]

--name=[object-name]

Optional parameter which filters for object with the given name.

Example:

$ cobbler reposync [--only=ONLY] [--tries=TRIES] [--no-fail]

Cobbler reposync is the command to use to update repos as configured with cobbler repo add. Mirroring can take a long time, and usage of cobbler reposync prior to usage is needed to ensure provisioned systems have the files they need to actually use the mirrored repositories. If you just add repos and never run cobbler reposync, the repos will never be mirrored. This is probably a command you would want to put on a crontab, though the frequency of that crontab and where the output goes is left up to the systems administrator.

For those familiar with dnf’s reposync, cobbler’s reposync is (in most uses) a wrapper around the dnf reposync command. Please use cobbler reposync to update cobbler mirrors, as dnf’s reposync does not perform all required steps. Also cobbler adds support for rsync and SSH locations, where as dnf’s reposync only supports what dnf supports (http/ftp).

If you ever want to update a certain repository you can run: cobbler reposync --only="reponame1" ...

When updating repos by name, a repo will be updated even if it is set to be not updated during a regular reposync operation (ex: cobbler repo edit –name=reponame1 –keep-updated=0). Note that if a cobbler import provides enough information to use the boot server as a yum mirror for core packages, cobbler can set up automatic installation files to use the cobbler server as a mirror instead of the outside world. If this feature is desirable, it can be turned on by setting yum_post_install_mirror to True in /etc/cobbler/settings.yaml (and running cobbler sync). You should not use this feature if machines are provisioned on a different VLAN/network than production, or if you are provisioning laptops that will want to acquire updates on multiple networks.

The flags --tries=N (for example, --tries=3) and --no-fail should likely be used when putting re-posync on a crontab. They ensure network glitches in one repo can be retried and also that a failure to synchronize one repo does not stop other repositories from being synchronized.

The sync command is very important, though very often unnecessary for most situations. It's primary purpose is to force a rewrite of all configuration files, distribution files in the TFTP root, and to restart managed services. So why is it unnecessary? Because in most common situations (after an object is edited, for example), Cobbler executes what is known as a "lite sync" which rewrites most critical files.

When is a full sync required? When you are using manage_dhcpd (Managing DHCP) with systems that use static leases. In that case, a full sync is required to rewrite the dhcpd.conf file and to restart the dhcpd service.

Cobbler sync is used to repair or rebuild the contents /tftpboot or /var/www/cobbler when something has changed behind the scenes. It brings the filesystem up to date with the configuration as understood by Cobbler.

Sync should be run whenever files in /var/lib/cobbler are manually edited (which is not recommended except for the settings file) or when making changes to automatic installation files. In practice, this should not happen often, though running sync too many times does not cause any adverse effects.

If using Cobbler to manage a DHCP and/or DNS server (see the advanced section of this manpage), sync does need to be run after systems are added to regenerate and reload the DHCP/DNS configurations. If you want to trigger the DHCP/DNS regeneration only and do not want a complete sync, you can use cobbler sync --dhcp or cobbler sync --dns or the combination of both.

cobbler sync --systems is used to only write specific systems (must exists in backend storage) to the TFTP folder. The expected pattern is a comma separated list of systems e.g. sys1.internal,sys2.internal,sys3.internal.

NOTE:

The sync process can also be kicked off from the web interface.

Example:

$ cobbler sync
$ cobbler sync [--systems=sys1.internal,sys2.internal,sys3.internal]
$ cobbler sync [--dns]
$ cobbler sync [--dhcp]
$ cobbler sync [--dns --dhcp]

Example:

$ cobbler validate-autoinstalls

Example:

$ cobbler version

Example:

$ cobbler signature

Example:

$ cobbler hardlink

This command is used for generating UEFI bootable GRUB 2 bootloaders. This command has no options and is configured via the settings file of Cobbler. If available on the operating system Cobbler is running on, then this also generates bootloaders for different architectures then the one of the system.

NOTE:

Example:

$ cobbler mkloaders