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.
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:> 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.
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
2012-Jul-05 16:26 UTC
Re: [Puppet Users] Re: Identifying host OS in an ENC
On Thu, Jul 5, 2012 at 4:56 PM, jcbollinger <John.Bollinger@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. -- 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.
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.