Identifying host OS in an ENC

[Matthew Burgess]

Hi all,

We have a mixed Linux and Windows environment and have so far just
been using Puppet on our Linux servers. Having configured the
inventory service, we've got an auditing script that uses the data to
report on things like OS version, RAM, etc. This is all so nice that
we'd like to extend it to auditing our Windows infrastructure.
However, at this point in time, we have no need to apply any manifests
to those Windows servers, and they're all Linux-centric anyway.

I've installed the puppet agent on a Windows server but when it starts
it obviously tries to apply all the manifests the ENC tells it to
(there's a default set of classes that all servers up until now have
applied). I think the correct way to tackle this is to have the first
run of the agent use the 'noop' parameter, that way the cert exchange
will take place, and the facts will be populated, but no classes will
be applied. On subsequent runs, the ENC can use the aforementioned
inventory service to inspect the 'operatingsystem' fact to determine
whether or not to apply any classes.

So, I guess, I'm just babbling to the masses here in a request for
comments as to whether this is the correct/most efficient method of
achieving my goal of only applying classes to Linux servers, but being
able to have Windows servers available via the inventory service.

Thanks,

Matt.

[ad]

Hey Matt,

I'm not exactly sure how you have things setup now, but the operating
system fact is baked into factor and will be available on the first
run. Rather than having the ENC supply your default classes, you could
do so in your site.pp. Here's how I do it:

stage { 'first': before => Stage['main'] }
class { baselinux: stage => 'first' }

This makes baselinux run for every node, before anything else,
independent of the ENC. It would be easy enough to wrap that in a OS
check.

We have a similar setup (just starting work on Windows primarily for
auditing as well) and decided to use a separate Puppet Master for
Windows to keep things clean and other reasons such as different
operations teams administering the ENC.

hth,

Adam

p.s. If you haven't explored this, you can do some really cool things
with Windows auditing by extending factor and using Ruby's win32/ole
libraries (report on video cards, motherboards, etc.)

On Jul 4, 8:20 am, Matthew Burgess <matthew.2.burg...@googlemail.com>
wrote:

[jcbollinger]

On Wednesday, July 4, 2012 8:20:51 AM UTC-5, Matthew Burgess wrote:

Hi all,

We have a mixed Linux and Windows environment and have so far just
been using Puppet on our Linux servers.  Having configured the
inventory service, we've got an auditing script that uses the data to
report on things like OS version, RAM, etc.  This is all so nice that
we'd like to extend it to auditing our Windows infrastructure.
However, at this point in time, we have no need to apply any manifests
to those Windows servers, and they're all Linux-centric anyway.

I've installed the puppet agent on a Windows server but when it starts
it obviously tries to apply all the manifests the ENC tells it to
(there's a default set of classes that all servers up until now have
applied).  I think the correct way to tackle this is to have the first
run of the agent use the 'noop' parameter, that way the cert exchange
will take place, and the facts will be populated, but no classes will
be applied.  On subsequent runs, the ENC can use the aforementioned
inventory service to inspect the 'operatingsystem' fact to determine
whether or not to apply any classes.

Are you sure a Puppet run needs to have already completed before the facts are available from the inventory service?  That would be surprising.  Also most unfortunate, inasmuch as it implies that the inventory service would be serving stale facts (from a previous run) to your ENC.

The old-school way of accessing node facts from an ENC was to load the master's YAML-formatted fact cache.  You could fall back to that if the inventory service really doesn't meet your first-run needs.

John

[Matthew Burgess]

On Thu, Jul 5, 2012 at 4:56 PM, jcbollinger <John.Bo...@stjude.org> wrote:

> Are you sure a Puppet run needs to have already completed before the facts
> are available from the inventory service? That would be surprising. Also
> most unfortunate, inasmuch as it implies that the inventory service would be
> serving stale facts (from a previous run) to your ENC.

Well, no, to be honest, I'm not sure how the facts are made available
to the ENC/inventory service.

From what you've written above, I assume the order of events is:

1) puppet agent runs
2) puppet agent gathers facts
3) puppet agent stores facts in inventory service
4) puppet server uses facts during compilation and application of the catalog?

If that's the case, then all is good, I guess.

Thanks,

Matt.

[jcbollinger]

On Thursday, July 5, 2012 11:26:48 AM UTC-5, Matthew Burgess wrote:

On Thu, Jul 5, 2012 at 4:56 PM, jcbollinger wrote:

> Are you sure a Puppet run needs to have already completed before the facts
> are available from the inventory service?  That would be surprising.  Also
> most unfortunate, inasmuch as it implies that the inventory service would be
> serving stale facts (from a previous run) to your ENC.

Well, no, to be honest, I'm not sure how the facts are made available
to the ENC/inventory service.

From what you've written above, I assume the order of events is:

1) puppet agent runs
2) puppet agent gathers facts
3) puppet agent stores facts in inventory service
4) puppet server uses facts during compilation and application of the catalog?

If that's the case, then all is good, I guess.

What I know is:
1) The agent performs plugin synchronization, if enabled
2) The agent gathers facts and sends them to the master
3) The master compiles and returns a catalog
4) The agent applies the catalog

Recording the facts in the inventory service and running the ENC both happen in step 3.  The ENC runs very early, and I don't know for sure whether the inventory is updated first, but the master definitely has the node's then-current facts somewhere at that time.  If the inventory isn't updated first then I'd consider filing a bug / RFE.


John