FAQ
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.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Ad at Jul 5, 2012 at 2:35 pm
    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 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.

    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.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jul 5, 2012 at 3:56 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/u7fssAmrISYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Matthew Burgess at Jul 5, 2012 at 4:27 pm

    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.

    Thanks,

    Matt.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jul 5, 2012 at 9:48 pm

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/2sZX6nE20g4J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 4, '12 at 1:20p
activeJul 5, '12 at 9:48p
posts5
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase