On Fri, Sep 4, 2009 at 3:44 AM, Kenneth Holter wrote:
>
> Thanks for all the replies - this looks very promising wrt gaining more
> control over our node definitions (and inventory). It seems like having the
> puppetmaster fetch client info from a database is a far better approach than
> having th
On 9/4/09, Ohad Levy wrote:
>
>
>>
> 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 ru
On Fri, Sep 4, 2009 at 3:44 PM, Kenneth Holter 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,
Thanks for all the replies - this looks very promising wrt gaining more
control over our node definitions (and inventory). It seems like having the
puppetmaster fetch client info from a database is a far better approach than
having the puppetmaster push info into one.
If I understand correctly, st
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 = YAM
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 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.
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 Holt
Kenneth Holter 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
> configurati
On Sep 1, 2009, at 3:28 PM, Disconnect wrote:
>
> 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..
Keep in mind while iclassify works, the original developers
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 wrote:
> Hi all.
> We have a bunch of RHEL servers running Puppet. Th
I am using external node classifiers that parse information FROM a database
(well really a csv file, but it could easily be a database:) in order to
build the classifications. This is the opposite of what you are proposing,
here its the database that controls how puppet classifies machines, not the
11 matches
Mail list logo
