Is this an intended behavior? And if so, is something wrong with my
capsules (smart proxies) that they are not writing my subnets to dhcpd.conf?
To replicate this, make a modification to /etc/dhcp/dhcpd.conf, and then
run something like foreman-installer --foreman-proxy-bmc "true", and the
conf will be rewritten, but with none of the modified information (not even
when I have subnets defined in the foreman UI)
Would love to figure out what's causing this, or if it's intended.
Adding einjen_ from IRC. He had the same issue, including overwriting his
DNS config.
mandag 3. oktober 2016 22.58.49 UTC+2 skrev nha...@kayak.com følgende:
>
> Is this an intended behavior? And if so, is something wrong with my
> capsules (smart proxies) that they are not writing my subnets to dhcpd.conf?
>
> To replicate this, make a modification to /etc/dhcp/dhcpd.conf, and then
> run something like foreman-installer --foreman-proxy-bmc "true", and the
> conf will be rewritten, but with none of the modified information (not even
> when I have subnets defined in the foreman UI)
>
> Would love to figure out what's causing this, or if it's intended.
>
This has been affecting me too.
Quite annoying.
Einar
It is intended yes. Broadly speaking, there are two use cases:
A brand new user, with no Foreman installed yet, wants to manage a basic
setup (single network) with DHCP and DNS.
Ana existing user wants to add the Subnets and Domains to his proxy from
Foreman via a configuration management tool.
The issue is that the foreman-installer is only set up for case (1) - it
uses our puppet-dhcp and puppet-dns modules underneath, but the abstraction
in foreman-installer is quite basic, and really only works for a single
network. Further, foreman-installer stores it's answers in a cache file,
and doesn't reference Foreman for data (because for 95% of it's work, there
is no Foreman instance to query).
What you want sounds like (2) to me - that is, you wish to deploy Subnets
and Domains from Foreman to your proxies. However, we'reinto new territory
now - Foreman's general rule of thumb is that it doesn't modify configs if
it can avoid it, as that's the job of config management.
The usually recommended solution is to use the puppet-dhcp and puppet-dns
modules directly on your proxies, passing in the appropriate data. This
could be statically entered or generated using ERB in the class parameters
(presumably you'd want some subnet of Subnet.all and Domain.all). Once
properly configured, you'd have the proxies deploying new subnets and
domains direct from the Foreman UI data.
I appreciate that's probably more work than you were looking for, but
there's no way around it (and you're far from the first to stumble over
this). The foreman-installer isn't designed for complex networks, it's for
bootstrapping a basic Foreman setup with all the working features (even if
some are off by default).
Hope that helps!
Greg
Sure. That definitely makes sense.
It does seem logical to me that foreman would manage DHCP/DNS on a proxy if
it's installed, but I also understand why this isn't the case.
Is the rule of thumb just to… not run foreman-install if you can avoid it?
It is intended yes. Broadly speaking, there are two use cases:
A brand new user, with no Foreman installed yet, wants to manage a
basic setup (single network) with DHCP and DNS.Ana existing user wants to add the Subnets and Domains to his proxy
from Foreman via a configuration management tool.The issue is that the foreman-installer is only set up for case (1) - it
uses our puppet-dhcp and puppet-dns modules underneath, but the abstraction
in foreman-installer is quite basic, and really only works for a single
network. Further, foreman-installer stores it’s answers in a cache file,
and doesn’t reference Foreman for data (because for 95% of it’s work, there
is no Foreman instance to query).What you want sounds like (2) to me - that is, you wish to deploy Subnets
and Domains from Foreman to your proxies. However, we’reinto new territory
now - Foreman’s general rule of thumb is that it doesn’t modify configs if
it can avoid it, as that’s the job of config management.The usually recommended solution is to use the puppet-dhcp and puppet-dns
modules directly on your proxies, passing in the appropriate data. This
could be statically entered or generated using ERB in the class parameters
(presumably you’d want some subnet of Subnet.all and Domain.all). Once
properly configured, you’d have the proxies deploying new subnets and
domains direct from the Foreman UI data.I appreciate that’s probably more work than you were looking for, but
there’s no way around it (and you’re far from the first to stumble over
this). The foreman-installer isn’t designed for complex networks, it’s for
bootstrapping a basic Foreman setup with all the working features (even if
some are off by default).Hope that helps!
Greg–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
KAYAK
Neil Hanlon
Devops Engineer
+1 978 902 8171
> Sure. That definitely makes sense.
>
> It does seem logical to me that foreman would manage DHCP/DNS on a proxy
> if it's installed, but I also understand why this isn't the case.
>
It does makes logical sense, thats the problem 
- this is just a case of
two things that make sense conflicting and one of them (in this case the
"don't change stuff directly" rule") having to win. I may try to write a
blog post on consuming those two modules at some point, but I'm not
promising
> Is the rule of thumb just to… not run foreman-install if you can avoid
> it?
>
It's not a bad rule, although it is up for debate (this manual suggests it
after a major version upgrade, for example).
My approach is to use it to set up a new instance of Foreman and then
import the installer modules into the newly-created puppetmaster (and
configure the UI to pass the same overrides that I used on the cmdline, if
any). It's a touch more work up front, but that way I'm doing the same
thing as running the installer (but every half-hour), with the advantadge
of knowing exactly what's being passed to Puppet (and thus the option of
tweaking it in the future).
HTH
Greg
Haha I totally get it. I'm in a weird situation since we have puppet
running externally and also alongside our foreman setup while we evaluate
and prepare to switch over to have foreman handle being the puppet
master/ca/etc. All very confusing. For now I think I'll manage DHCP for my
production environment manually and just create a file like
"/etc/dhcp/subnets.conf" which I can force-include after I run
foreman-installer (if I ever do).
On 3 October 2016 at 22:28, Neil Hanlon nhanlon@kayak.com wrote:
Sure. That definitely makes sense.
It does seem logical to me that foreman would manage DHCP/DNS on a proxy
if it’s installed, but I also understand why this isn’t the case.It does makes logical sense, thats the problem
two things that make sense conflicting and one of them (in this case the
"don’t change stuff directly" rule") having to win. I may try to write a
blog post on consuming those two modules at some point, but I’m not
promisingIs the rule of thumb just to… not run foreman-install if you can avoid
it?It’s not a bad rule, although it is up for debate (this manual suggests it
after a major version upgrade, for example).My approach is to use it to set up a new instance of Foreman and then
import the installer modules into the newly-created puppetmaster (and
configure the UI to pass the same overrides that I used on the cmdline, if
any). It’s a touch more work up front, but that way I’m doing the same
thing as running the installer (but every half-hour), with the advantadge
of knowing exactly what’s being passed to Puppet (and thus the option of
tweaking it in the future).HTH
Greg–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
KAYAK
Neil Hanlon
Devops Engineer
+1 978 902 8171
That works, sure. Ultimately, the power is in the users hands - the data
can be exposed vi the ENC in a variety of ways, so it can be handled by a
cfg mgmt agent, or it can be decoupled (or something else again, such as
using the Foreman API, which may be how I handle this blog post, if I ever
write it…)
Good luck!
Greg
Haha I totally get it. I’m in a weird situation since we have puppet
running externally and also alongside our foreman setup while we evaluate
and prepare to switch over to have foreman handle being the puppet
master/ca/etc. All very confusing. For now I think I’ll manage DHCP for my
production environment manually and just create a file like
"/etc/dhcp/subnets.conf" which I can force-include after I run
foreman-installer (if I ever do).
mandag 3. oktober 2016 23.45.59 UTC+2 skrev Greg Sutcliffe følgende:
>
>
>> Haha I totally get it. I'm in a weird situation since we have puppet
>> running externally and also alongside our foreman setup while we evaluate
>> and prepare to switch over to have foreman handle being the puppet
>> master/ca/etc. All very confusing. For now I think I'll manage DHCP for my
>> production environment manually and just create a file like
>> "/etc/dhcp/subnets.conf" which I can force-include after I run
>> foreman-installer (if I ever do).
>>
>>
> That works, sure. Ultimately, the power is in the users hands - the data
> can be exposed vi the ENC in a variety of ways, so it can be handled by a
> cfg mgmt agent, or it can be decoupled (or something else again, such as
> using the Foreman API, which may be how I handle this blog post, if I ever
> write it…)
>
> Good luck!
> Greg
>
Thanks for the explanation. It makes sense, I think.
the installer is not to be used ever again after install, right?
It's fine to maintain what the installer set up in the first place - but
most people will grow their install over time (adding more domains, subnets
etc) which the installer doesn't know about. In the latter case, the
installer can't maintain them.
Thanks for the explanation. It makes sense, I think.
the installer is not to be used ever again after install, right?