Puppet users - May 2009 - Configuring hosts with data from other hosts

So I want to use facts from one host in the configuration of other
hosts.
Trivial example: setting restrict lines in ntp.conf to allow a
monitoring host to query ntpd on remote hosts.

So if the monitoring host boots with IP 10.2.2.3 (which may change
regularly), and it knows its the monitor host (via some customer
facter plugins), I want some global variable to be available
($monitor_host_ipaddress, type of thing) which could be used in
tempaltes etc for all other hosts.

Exported resources seems close to what I want, but I dont want to
export a file, and copy it to other machines. I want to use
variables.

Or do I have to copy the IP address of the monitor host to each
machine, via an exported resource file, and then process it locally in
an exec script to build the correct ntp.conf?
That doesn''t seem very puppet-ish...

Help?
T.I.A.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hello,

Am 12.05.2009 um 08:51 schrieb steverfrancis@gmail.com:
> Or do I have to copy the IP address of the monitor host to each
> machine, via an exported resource file, and then process it locally in
> an exec script to build the correct ntp.conf?
> That doesn''t seem very puppet-ish...
No, but I think you could build the ntp.conf for the clients on the  
monitor host (which knows its own IP adress :-) ) and distribute that  
through exported resources to the clients.

BR,

Felix

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

So how about a slightly less trivial example, such as configuring a
haproxy config based on the addresses of 2 web servers?

THe puppetmaster knows the addresses of the 2 web servers; it knows
the proxy is a proxy, and the form of the config file, but I cant see
how to put all that information together, except outside puppet. (Such
as having the web servers export their addresses to the puppetmaster,
which has an external script to use that information to modify the
template in the puppet configuration that the proxy module uses.)



On May 12, 12:04 am, Felix Schäfer <schae...@cypres-it.com>
wrote:
> Hello,
>
> Am 12.05.2009 um 08:51 schrieb steverfran...@gmail.com:
>
> > Or do I have to copy the IP address of the monitor host to each
> > machine, via an exported resource file, and then process it locally in
> > an exec script to build the correct ntp.conf?
> > That doesn''t seem very puppet-ish...
>
> No, but I think you could build the ntp.conf for the clients on the  
> monitor host (which knows its own IP adress :-) ) and distribute that  
> through exported resources to the clients.
>
> BR,
>
> Felix
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

what is the right way to handle this?

On Tuesday, May 12, 2009 7:51:31 AM UTC+1, stever...@gmail.com
wrote:
>
> So I want to use facts from one host in the configuration of other 
> hosts. 
> Trivial example: setting restrict lines in ntp.conf to allow a 
> monitoring host to query ntpd on remote hosts. 
>
> So if the monitoring host boots with IP 10.2.2.3 (which may change 
> regularly), and it knows its the monitor host (via some customer 
> facter plugins), I want some global variable to be available 
> ($monitor_host_ipaddress, type of thing) which could be used in 
> tempaltes etc for all other hosts. 
>
> Exported resources seems close to what I want, but I dont want to 
> export a file, and copy it to other machines. I want to use 
> variables. 
>
> Or do I have to copy the IP address of the monitor host to each 
> machine, via an exported resource file, and then process it locally in 
> an exec script to build the correct ntp.conf? 
> That doesn''t seem very puppet-ish... 
>
> Help? 
> T.I.A. 
>
>
-- 
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/-/8JqLcWgVaYUJ.
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 Tuesday, August 14, 2012 2:27:05 PM UTC-5, Sam wrote:
>
>
> what is the right way to handle this?
>
> On Tuesday, May 12, 2009 7:51:31 AM UTC+1, stever...@gmail.com wrote:
>>
>> So I want to use facts from one host in the configuration of other 
>> hosts. 
>> Trivial example: setting restrict lines in ntp.conf to allow a 
>> monitoring host to query ntpd on remote hosts. 
>>
>> So if the monitoring host boots with IP 10.2.2.3 (which may change 
>> regularly), and it knows its the monitor host (via some customer 
>> facter plugins), I want some global variable to be available 
>> ($monitor_host_ipaddress, type of thing) which could be used in 
>> tempaltes etc for all other hosts. 
>>
>> Exported resources seems close to what I want, but I dont want to 
>> export a file, and copy it to other machines. I want to use 
>> variables. 
>>
>> Or do I have to copy the IP address of the monitor host to each 
>> machine, via an exported resource file, and then process it locally in 
>> an exec script to build the correct ntp.conf? 
>> That doesn''t seem very puppet-ish... 
>>
>>
There are basically two kinds of data in Puppet: those managed by Puppet 
and those not.  Those that are managed by Puppet are within your control to 
distribute and share as you like.  Those that are not managed by Puppet, on 
the other hand, are inherently problematic for several reasons, among them 
that

   - Puppet cannot verify whether they are correct, nor make them correct 
   when they are wrong
   - Puppet cannot tell third-party nodes what the *expected* data values 
   are
   - Any record of the actual values you may make on the master is subject 
   to going stale without notice

Nevertheless, this sort of request is becoming more common.  If you cannot 
or will not convert unmanaged data to managed data, but you must 
nevertheless exchange it with other nodes, via the Puppet master, then the 
only built-in alternative is exported resources.

The original and main idea of exported resources is for the node that knows 
what a resource is actually supposed to look like to declare the node on 
behalf of the nodes that need it, which do not necessarily include the one 
that declares it.  The canonical example is probably a Host resource.

Exported resources can take you a long way, especially when you consider 
that you can export resources of defined and custom types, and that you can 
override resources'' properties when you collect them.  For example, you
can
use the Concat module''s defined types to build a custom file consisting
of
some stanzas contributed by the node for which the file is targeted and 
others contributed as exported fragments by other nodes.

If you insist upon going meta, or if there seems no other way, then 
consider that exported resources don''t have to be collected by any 
particular set of nodes, or even by any nodes at all.  Specifically, if 
your master is its own client, then you can export resources that will be 
collected only by the master, such as data or configuration files, or 
fragments of them.  If you do that, then you can use Puppet''s
generate()
function to run suitable local scripts or programs to extract the data you 
want from local files managed that way.

If you are using hiera, and you want to *really* make the snake bite its 
own tail then you could consider using that approach to manage hiera data 
files on the master.  Then your data would be available inside Puppet via 
hiera, with no need for (other) external programs or generate().  In Puppet 
3, that will allow you even to manage class parameter defaults.

Needless to say, the more meta you get, the more risk there is that your 
configuration will swallow itself and explode.


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/-/EL7f6rreVrEJ.
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, August 15, 2012 8:31:52 AM UTC-5, jcbollinger
wrote:
>
> The original and main idea of exported resources is for the node that 
> knows what a resource is actually supposed to look like to declare the node
> on behalf of the nodes that need it
>
>
I meant "declare the *resource* on behalf of the nodes that need it,"
of
course.


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/-/hsjFOTJdULcJ.
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.

Thanks jcbollinger!   Great reply!

-- 
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/-/0IUtFeEsDFcJ.
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.

Ive struggled with the same problem of distributing variables and other
generated data amongst hosts.

For external resources Ive found a great use in configuring a BackupPC server. 
Each node builds their backup configuration file with tag
''backuppc_server_conf'' and the server retrieves all the
generated files with that tag.

What I havent been unable to solve, is making each nodes hiera values accessable
to each other.  My hierarchy is $fqdn->common.  The very crude workaround Ive
used is in a module, query foreman for all fqdn''s.  Then pass that to a
define that ''redefines'' fqdn variable before calling hiera.

Is there alternatively a way to query resources like all mysql::db types?  I
would like to just get all the mysql::db instances on a given node so other
nodes could use that data.  This could be another way to configure backuppc or
generate monitoring checks.

- Trey

-- 
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/-/5a1FTfRCFSsJ.
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 Sun, Aug 19, 2012 at 10:31 AM, treydock <treydock@gmail.com> wrote:
> Ive struggled with the same problem of distributing variables and other
> generated data amongst hosts.
>
> For external resources Ive found a great use in configuring a BackupPC
> server.  Each node builds their backup configuration file with tag
> ''backuppc_server_conf'' and the server retrieves all the
generated files
> with that tag.
>
> What I havent been unable to solve, is making each nodes hiera values
> accessable to each other.  My hierarchy is $fqdn->common.  The very
crude
> workaround Ive used is in a module, query foreman for all fqdn''s. 
Then
> pass that to a define that ''redefines'' fqdn variable
before calling hiera.
>
> Is there alternatively a way to query resources like all mysql::db types?
>  I would like to just get all the mysql::db instances on a given node so
> other nodes could use that data.  This could be another way to configure
> backuppc or generate monitoring checks.
>
not sure if you already sorted that out or not, but thats the idea behind
the search function that queries foreman, see
 http://blog.theforeman.org/2012/01/getting-foreman-search-results-into.html

Ohad
>
> - Trey
>
> --
> 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/-/5a1FTfRCFSsJ.
> 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.
>
>
-- 
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.