and, I forgot, you are not forced to use store configs just for the inventory.
On Wed, Sep 2, 2009 at 9:27 AM, Ohad Levy <[email protected]> wrote: > I also recommend using external nodes and facts as inventory. > > if you are looking for an active project (unlike puppetshow and iclassiy) > you might consider gni. > it already does what you want, and more :) > http://wiki.github.com/ohadlevy/gni > > cheers, > Ohad > > > On Wed, Sep 2, 2009 at 1:00 AM, Kenneth Holter <[email protected]>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 >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
