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 --- certs: password_file_dir: "certs::params::password_file_dir" city: Raleigh org: Katello country: US generate: false server_cert_req: deploy: false regenerate_ca: false server_ca_cert: 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 server_key: state: "North Carolina" ca_common_name: <FQDN OF YOUR HOST> server_cert: ca_expiration: "36500" org_unit: SomeOrgUnit regenerate: false capsule: qpid_router_hub_addr: "0.0.0.0" freeipa_remove_dns: dhcp_nameservers: "<COMMA SEPARATED LIST OF NAMESERVERS DHCP WILL CONFIGURE>" pulp_admin_password: "" qpid_router_hub_port: "5646" realm_provider: freeipa dns_provider: nsupdate dns_managed: false dhcp_gateway: "<DEFAULT GATEWAY DHCP WILL CONFIGURE>" 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: "" dns_zone: dhcp_config: /etc/dhcp/dhcpd.conf tftp_syslinux_root: puppetca: false foreman_proxy_http_port: 8000 pulp_oauth_secret: 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 tftp_syslinux_files: pulp_oauth_effective_user: admin pulp: false dhcp: true realm_principal: "" realm_keytab: realm: false dns_forwarders:  dns_tsig_principal: dns_tsig_keytab: dhcp_range: "<DHCP RANGE, SPACE SEPARATED>" puppet_ca_proxy: "" foreman_proxy_http: true pulp_oauth_key: katello certs_tar: <PATH TO CERTS TAR GENERATED ON SATELLITE SERVER> parent_fqdn: <YOUR SATELLITE SERVER FQDN> bmc: false reverse_proxy_port: "8443" foreman_proxy_port: 9090 qpid_router_broker_addr: qpid_router_agent_addr: "0.0.0.0" qpid_router: true templates: false rhsm_url: /rhsm dhcp_key_secret: "" dhcp_key_name: "" dhcp_vendor: isc dhcp_interface: eth0 tftp_dirs: 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.
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.