[Puppet Users] Re: Storing puppet info in a database

Disconnect
Tue, 01 Sep 2009 19:28:02 -0000

We use iclassify - it works as an external node tool (feeds tags,
facts etc to puppetmaster) and clients feed it with automated info
(facts) and manual tags/info/descriptions/etc..

On Tue, Sep 1, 2009 at 1:00 PM, Kenneth Holter<kenneho.ndu@gmail.com>
wrote:
> Hi all.
> We have a bunch of RHEL servers running Puppet. They are also connected to
> our Red Hat Satellite server.
> Currently we don''t have any master documentation system that
stores all
> relevant information (i.e. type of server, hardware info, linux
> configuration, etc) about the servers. So what I''d like to do is
implement
> some sort of system that can hold all this information. There are a lot of
> asset management products that I guess could get us a long way (and our
> organization is probably going to buy one soon), but I''m not sure
how
> flexible these would be with regards to storing custom information and
such.
> The asset management product will be administred by someone else within the
> organisation, and having that person implement linux specific info (such as
> puppet) and stuff may not be very realistic.
> First of all, how to other people handle this sort of thing? Storing info
in
> excel-files is no good, since the information will be outdated by the time
I
> press "save". We need a more or less automatic way of doing this,
but is
> asset management products the way to go? Currently, our node definition in
> Puppet holds the most current infomation when it comes to confuguration,
> while Satellite server holds a lot of other information. I''m
hoping to
> integrate all our server info (including puppet) into a database
(preferably
> the Satellite server database on Oracle), so that we can query it for info.
> I''ve been playing around with two ideas for automating system
documentation:
> 1) Parse the puppet manifests (and node definitions) and organize the info
> in a database
> 2) Include a logging functionality in the puppet manifests, so that when
the
> clients implement the configuration it logs a specific text to syslog. The
> syslog message is sent over to our log host, which can parse it and store
> the information in a database.
> Maybe the first option is allready implemented? Anyway, have anyone
> implemented such mechanisms?
> Best regards,
> Kenneth Holter
> >