On Fri, Sep 4, 2009 at 3:44 PM, Kenneth Holter <[email protected]>wrote:
> > If I understand correctly, stored configs simply store the puppet client's > configuration in a database, while external nodes classification allows for > generating configurations based on contents in for example a database. > In our case, we have a Satellite server that store information in an Oracle > database, so incoorporating puppet info into that database sound very > elegant. This way we'll have one database that contains pretty much > everything. > You can pass in external nodes only lists of classes and variables that will be applied to the server, you cant store configuration in a database directly. > > As far as I can see, two questions still remain: > > 1. What's the most practical way of updating external node's database, > i.e. how to I create new nodes? I guess having a script that queries us for > misc info about new nodes, and updates the database accordingly, seems like > the most neat way of doing this. How are others doing this? Does such a > script allready exist? > 2. Can I have the puppet clients store info (for example hardware info > and such) in the same database? Perhaps this is where exported resources > comes in handy. > > GNI is doing both things you are asking, it can import your existing puppet nodes from the yaml files, and later on you can create new nodes though its interface. You will also get the inventory of the hosts in GNI web interface. > > 1. > > By the way, what are the arguments to choose stored configs over external > nodes classification? > > They are not really comparable, external nodes is used to define your hosts (in terms of classes and variables), where store config is mostly about changing one server configuration because of a change in a second server, for example, add a monitoring rule to your monitoring server each time you add a server. Ohad Best regards, > Kenneth > > > On 9/2/09, Joel Krauska <[email protected]> wrote: >> >> >> Puppet already stores a lot of this data in YAML. >> >> Take a look at >> /var/lib/puppet/yaml/facts/ >> >> Here's a quick and dirty perl tool. >> (it needs the YAML perl module to work) >> >> #!/usr/bin/perl >> use YAML; >> >> $facts ='/var/lib/puppet/yaml/facts/*.yaml'; >> >> foreach my $file ( glob $facts ) { >> my $data = YAML::LoadFile($file); >> my $values = $data->{values}; >> my $name = $data->{name}; >> $kernellist{$values->{kernelrelease}}++; >> $memlist{$values->{memorysize}}++; >> } >> >> print "---------------------------------------------\n"; >> print "Kernel Counts\n"; >> print "---------------------------------------------\n"; >> foreach my $item (sort keys %kernellist) { >> print "$kernellist{$item} \t $item\n"; >> } >> >> >> print "\n\n"; >> print "---------------------------------------------\n"; >> print "RAM Counts\n"; >> print "---------------------------------------------\n"; >> foreach my $item (sort keys %memlist) { >> >> print "$memlist{$item} \t $item\n"; >> } >> >> >> >> >> example output: >> --------------------------------------------- >> Kernel Counts >> --------------------------------------------- >> 1 2.6.16.27-0.9-smp >> 37 2.6.16.53-0.16-smp >> 9 2.6.16.53-0.8-smp >> 12 2.6.16.54-0.2.5-smp >> 3 2.6.20-17-server >> 8 2.6.24-16-server >> 12 2.6.24-19-server >> >> etc... >> >> You can create custom facts to grab the type of information you want >> and puppet will store that in YAML too. >> >> Happy puppeting. >> >> --joel >> >> >> >> On Tue, Sep 1, 2009 at 6:28 PM, Ohad Levy<[email protected]> wrote: >> > 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 -~----------~----~----~----~------~----~------~--~---
