Deploying to subnet with no DNS

Duncan_Innes · February 11, 2016, 2:29pm

Struggling a bit to get a Satellite to deploy new systems to our DMZ
subnets. The problem we're facing is that there is no DHCP or DNS allowed
in the DMZ, so we need to generate boot ISO images that use IP addresses
rather than URL's for all network requests.

I figure we can fix the kickstarts by using a %pre script to add some
/etc/hosts entries before any of the kickstart process begins, but altering
the boot ISO's is proving more difficult.

Has anyone else managed to get boot ISO's and kickstarting functioning in
networks that have no DNS?

Thanks

Duncan

Gwmngilfen · February 11, 2016, 5:14pm

Do you mean the boot ISOs as generated by the bootdisk plugin? If so, then
I would assume it should use the value of unattended_url from the settings
page - you could set that to an IP for testing, but it's global so it may
affect things provisioned from elsewhere on the network. However, once you
have the ISO, you could probably set it back

More seriously, making unattended_url a per-subnet settings was previously
discussed quite a while ago - perhaps it's time to fix that…

···

On 11 February 2016 at 14:29, Duncan Innes wrote:

Struggling a bit to get a Satellite to deploy new systems to our DMZ
subnets. The problem we’re facing is that there is no DHCP or DNS allowed
in the DMZ, so we need to generate boot ISO images that use IP addresses
rather than URL’s for all network requests.

I figure we can fix the kickstarts by using a %pre script to add some
/etc/hosts entries before any of the kickstart process begins, but altering
the boot ISO’s is proving more difficult.

Has anyone else managed to get boot ISO’s and kickstarting functioning in
networks that have no DNS?

Duncan_Innes · February 12, 2016, 10:01am

Yes - we've poked around with the ISO on a test machine, but we'll be
looking to deploy a few hundred systems in the DMZ zones once the Satellite
finally goes live. We'd been looking at trying to set a couple of hard
coded entries in /etc/hosts as that's effectively what we're doing in the
%pre script for the kickstarts.

But you're definitely right about unattended_url being a per-subnet
setting. We will have Capsules all over the network; some completely
firewalled off from the Satellite, some just geographically separated.
Some of our clients will be able to see the Satellite, but others will be
completely unable to communicate with anything other than the local
Capsule. I'll raise a RH Support ticket for it from that end. Should I
raise a Foreman ticket too?

D

···

On Thursday, 11 February 2016 17:14:06 UTC, Greg Sutcliffe wrote: > > On 11 February 2016 at 14:29, Duncan Innes <dun...@innes.net > > wrote: > >> Struggling a bit to get a Satellite to deploy new systems to our DMZ >> subnets. The problem we're facing is that there is no DHCP or DNS allowed >> in the DMZ, so we need to generate boot ISO images that use IP addresses >> rather than URL's for all network requests. >> >> I figure we can fix the kickstarts by using a %pre script to add some >> /etc/hosts entries before any of the kickstart process begins, but altering >> the boot ISO's is proving more difficult. >> >> Has anyone else managed to get boot ISO's and kickstarting functioning in >> networks that have no DNS? >> > > Do you mean the boot ISOs as generated by the bootdisk plugin? If so, then > I would assume it should use the value of unattended_url from the settings > page - you could set that to an IP for testing, but it's global so it may > affect things provisioned from elsewhere on the network. However, once you > have the ISO, you could probably set it back ;) > > More seriously, making unattended_url a per-subnet settings was previously > discussed quite a while ago - perhaps it's time to fix that... >

Gwmngilfen · February 12, 2016, 11:03am

> Yes - we've poked around with the ISO on a test machine, but we'll be
> looking to deploy a few hundred systems in the DMZ zones once the Satellite
> finally goes live. We'd been looking at trying to set a couple of hard
> coded entries in /etc/hosts as that's effectively what we're doing in the
> %pre script for the kickstarts.
>

The script that bootdisk uses to generate the ISO isn't very complex, and
could probably be extended. Have a look at

github.com

theforeman/foreman_bootdisk/blob/d344850abdbea212882043ac20068d9cb9371092/app/services/foreman_bootdisk/renderer.rb#L32


    modified_template = unattended_render(tmpl.template)
    # remove the token from subnet-level generation, since this is meant to be generic
    modified_template.gsub!(/(?<=iPXE\?)token=faketoken\&(?=mac=)/,'')
    modified_template
  end


  def bootdisk_chain_url(mac = '', action = 'iPXE')
    Renderer.format_bootdisk_chain_url(foreman_url(action), mac)
  end


  def self.format_bootdisk_chain_url(url, mac)
    u = URI.parse(url)
    ForemanBootdisk.logger.warn("Foreman or proxy is configured with HTTPS, probably not supported by iPXE: #{u}") if u.scheme == 'https'
    u.query = "#{u.query}&mac=#{mac}"
    u.fragment = nil
    u.to_s
  end
end
end

which is where the bootdisk iPXE script renders the foreman url.

> But you're definitely right about unattended_url being a per-subnet
> setting. We will have Capsules all over the network; some completely
> firewalled off from the Satellite, some just geographically separated.
> Some of our clients will be able to see the Satellite, but others will be
> completely unable to communicate with anything other than the local
> Capsule. I'll raise a RH Support ticket for it from that end. Should I
> raise a Foreman ticket too?
>

Sounds good, thanks!

···

On 12 February 2016 at 10:01, Duncan Innes wrote:

lzap · February 12, 2016, 4:44pm

> The script that bootdisk uses to generate the ISO isn't very complex, and
> could probably be extended. Have a look at
> https://github.com/theforeman/foreman_bootdisk/blob/d344850abdbea212882043ac20068d9cb9371092/app/services/foreman_bootdisk/renderer.rb#L32
> which is where the bootdisk iPXE script renders the foreman url.

You need to make sure your alternative hostname is included in the
certificate, otherwise https won't work against Satellite.

Also keep in mind when using Templates feature, foreman_url actually
renders to smart-proxy (Capsule).

It should be possible to change configuration so both values are plain
IP addresses.

···

-- Later, Lukas #lzap Zapletal

Duncan_Innes · February 13, 2016, 9:21am

We're having trouble with the corporate CA owner already. Multiple addresses in the cert aren't likely to be possible at this point. We might only get an unsigned cert from them at this point!

Our layout of Satellite and capsules is making it hard for us to see the foreman_url and unattended_url changing to the right Capsule all the time. We seem to be getting variable results. If there's some calculation behind how these change, we're not understanding it. A per-subnet setting would be much simpler surely? From a user perspective that is.