
# Are you using a Red Hat management platform in addition to Cobbler?
# Cobbler can help you register to it. Choose one of the following:
# "off" : I'm not using Red Hat Network, Satellite, or Spacewalk
# "hosted" : I'm using Red Hat Network
# "site" : I'm using Red Hat Satellite Server or Spacewalk
# You will also want to read: https://fedorahosted.org/cobbler/wiki/TipsForRhn
redhat_management_type: "site"
# if redhat_management_type is enabled, choose your server
# "management.example.org" : For Satellite or Spacewalk
# "xmlrpc.rhn.redhat.com" : For Red Hat Network
# This setting is also used by the code that supports using Spacewalk/Satellite users/passwords
# within Cobbler Web and Cobbler XMLRPC. Using RHN Hosted for this is not supported.
# This feature can be used even if redhat_management_type is off, you just have
# to have authn_spacewalk selected in modules.conf
redhat_management_server: "sat-vm.cloud.lab.eng.bos.redhat.com"
# specify the default Red Hat authorization key to use to register
# system. If left blank, no registration will be attempted. Similarly
# you can set the --redhat-management-key to blank on any system to
# keep it from trying to register.
redhat_management_key: ""
# if using authn_spacewalk in modules.conf to let cobbler authenticate
# against Satellite/Spacewalk's auth system, by default it will not allow per user
# access into Cobbler Web and Cobbler XMLRPC.
# in order to permit this, the following setting must be enabled HOWEVER
# doing so will permit all Spacewalk/Satellite users of certain types to edit all
# of cobbler's configuration.
# these roles are: config_admin and org_admin
# users should turn this on only if they want this behavior and
# do not have a cross-multi-org separation concern. If you have
# a single org in your satellite, it's probably safe to turn this
# on and then you can use CobblerWeb alongside a Satellite install.
redhat_management_permissive: 1
# when DHCP and DNS management are enabled, cobbler sync can automatically
# restart those services to apply changes. The exception for this is
# if using ISC for DHCP, then omapi eliminates the need for a restart.
# omapi, however, is experimental and not recommended for most configurations.
# If DHCP and DNS are going to be managed, but hosted on a box that
# is not on this server, disable restarts here and write some other
# script to ensure that the config files get copied/rsynced to the destination
# box. This can be done by modifying the restart services trigger.
# Note that if manage_dhcp and manage_dns are disabled, the respective
# parameter will have no effect. Most users should not need to change
# this.
restart_dns: 1
www.redhat.com 164
Comentarios a estos manuales