Unfinished Development Web Development, Infrastructure & Testing

RedHat Satellite with Katello Capsules for DHCP

On my current project we came up against an issue with FreeBSD (or any BSD flavour, apparently) being unable to relay DHCP across a VPN connection, due to the way virtual interfaces are handled (basically, there is no hardware address assigned so there is nothing to bind to). We are using pfSense for our firewalls so moving from BSD was not an option.

As we are using RedHat Satellite to manage our DHCP through a capsule we decided to try and use capsules in each Virtual Datacenter (VDC) to avoid the need for relaying but ensure Satellite managed all of our DHCP addresses.

In the later releases of RedHat satellite the licensing of capsules appears to have changed, meaning you no longer get any capsule licenses included in your Satellite subscription. This appears to be the way in which RedHat encourage you to use capsules and locations, meaning a Satellite Capsule is almost a full Satellite instance; therefore costing almost the same as a Satellite subscription. As the project is currently a proof of concept we couldn't justify the cost of a Satellite capsule.

Katello to the Rescue, perhaps

As Satellite uses Katello as an upstream project we decided to experiment with using a Katello capsule with Satellite. We figured that as the functionality we wanted to use within the capsule was so simple it may just work.

Installing the Capsule

The first issue we came up against was the reason we were trying to install the capsule in the first place; we couldn't boot the host and get an IP from DHCP as the relay wasn't working. This was easily solved by generating a boot disk within Satellite for the host, mounting the ISO file and boot the virtual manchine.

We went about installing the capsule according to the Katello documentation, the only real difference being that the required respositories were added into our Satellite server and the required packages were installed from there.

The command that the capsule-certs-generate command outputs won't give us what we want as that will enable the content capsule and a puppetmaster but will not enable the DHCP functionality. I had a number of issues with passing parameters into the installer - I haven't done enough digging to decide if this was me or an actual issue with what I was trying to do yet - so I ran the installer in interactive mode and ensured the required values were set.

I won't go in to every option that you need to set, suffice to say you want to ensure all capsule functionality, except for DHCP is disabled. Below is the answer file that was generated by the installer, so you may which to modify this and use it instead of passing in parameters or running in interactive mode

# Format:
# <classname>: false - don't include this class
# <classname>: true - include and use the defaults
# <classname>:
#   <param>: <value> - include and override the default(s)
# See params.pp in each class for what options are available

    password_file_dir: "certs::params::password_file_dir"
    city: Raleigh
    org: Katello
    country: US
    generate: false
    deploy: false
    regenerate_ca: false
    expiration: "7300"
    log_dir: /var/log/certs
    server_ca_name: katello-server-ca
    group: root
    pki_dir: /etc/pki/katello
    node_fqdn: <FQDN OF YOUR HOST>
    default_ca_name: katello-default-ca
    user: root
    ssl_build_dir: /root/ssl-build
    state: "North Carolina"
    ca_common_name: <FQDN OF YOUR HOST>
    ca_expiration: "36500"
    org_unit: SomeOrgUnit
    regenerate: false
    qpid_router_hub_addr: ""
    pulp_admin_password: ""
    qpid_router_hub_port: "5646"
    realm_provider: freeipa
    dns_provider: nsupdate
    dns_managed: false
    foreman_oauth_key: <YOUR FOREMAN OAUTH KEY>
    dns_interface: eth0
    puppet: false
    foreman_oauth_effective_user: admin
    register_in_foreman: true
    virsh_network: default
    dns_ttl: ""
    dhcp_config: /etc/dhcp/dhcpd.conf
    puppetca: false
    foreman_proxy_http_port: 8000
    qpid_router_agent_port: "5647"
    foreman_oauth_secret: <YOUR FOREMAN OAUTH SECRET KEY>
    tftp_root: /var/lib/tftpboot/
    dns: false
    dhcp_leases: /var/lib/dhcpd/dhcpd.leases
    dhcp_managed: true
    bmc_default_provider: ipmitool
    pulp_oauth_effective_user: admin
    pulp: false
    dhcp: true
    realm_principal: ""
    realm: false
    dns_forwarders: []
    dhcp_range: "<DHCP RANGE, SPACE SEPARATED>"
    puppet_ca_proxy: ""
    foreman_proxy_http: true
    pulp_oauth_key: katello
    bmc: false
    reverse_proxy_port: "8443"
    foreman_proxy_port: 9090
    qpid_router_agent_addr: ""
    qpid_router: true
    templates: false
    rhsm_url: /rhsm
    dhcp_key_secret: ""
    dhcp_key_name: ""
    dhcp_vendor: isc
    dhcp_interface: eth0
    tftp: false
    reverse_proxy: false
    qpid_router_broker_port: "5671"
    dns_server: ""
    dns_reverse: ""
    tftp_servername: ""
    pulp_master: false

After running the installer it will register the capsule with your Satellite server. For some reason the installer log complains and says that this step has failed, even though the capsule will have been successfully registered with the Satellite server (be aware that it will register without any locations or organisation assigned).

Looking at the installer logs, the error seems to be around missing gems or methods for foreman_api, but again I haven't had the chance to dig into this further and understand it.

Configure Satellite

The final step is to configure Satellite to use the new capsule for the subnets that require it; each of our VDCs run on separate subnets to ensure complete separation. This can be done from within the subnet form (Infrastructure --> Subnets). Be sure to only set the DHCP capsule to this new capsule.

You can of course enable further functionality on the capsule, such as DNS and TFTP, however I haven't tried that yet.


Using a Katello capsule with RedHat Satellite appears to work exactly as we required - our requirements were very simple. We have been using this architecture for a little while now and have built a number of virtual mahcines in a number of VDCs with no issues, so all in all it appears to be very successful.

The only issue we did have was the installer reporting that it failed, even though everything appears to have worked correctly. This requires further investigation to understand if we have missed a step or dependency, there is an issue with the installer itself or if there genuinely was an error and we have just been lucky enough to not hit it in our testing.

I wouldn't recommend this for a production solution - if our proof of concept moves to production then we will be upgrading our Katello capsules to full blown RedHat Satellite capsules, however it got us out of a jam and enabled us to prove a mechanism without spending thousands of pounds.