On Wednesday, July 25, 2012 3:39:24 PM UTC-5, Nikolaos Hatzopoulos wrote:
>
> so we define that file would be exported from node1 like:
>
> @@file { "etc/mynode.txt:":
> content => "${mycontent}"
> }
>
Basically, yes, but
1. You need to specify an absolute path, such as "/etc/mynode.txt"
2. The title or path you need to specify is the one you want the target
file to have on *node2* (the node that collects the resource). That can
be the same as the original file name, but it does not need to be.
3. If that resource is going to be exported from more than one node,
then each resource title should be unique across all nodes. Incorporating
an identifier for the exporting node is one way to accomplish that. You
should be able to use the 'path' property to specify a target filename and
path different from the resource title if you should need to do so.
> and on the node2
>
> File <| |>> ?? I want only the info from node1 not from all nodes that
> means I have to group the nodes for the specific action?
> who it works here? I am pretty new in puppet but I didn't get it from the
> documentation
>
I have no idea what the specifics of your situation are, so I'm trying to
point you in the right direction, not to hand you a boxed solution to the
problem. You can restrict the resources that will be collected by putting
a selection predicate in the "<<| |>>" spaceship operator. You should be
able to select by title, or it can be very convenient to apply a tag to
your resource and select by that. For example:
#
# For node1
#
# This assumes that only one node will export this file:
@@file { "/etc/mynode.txt":
ensure => file,
content => "${mycontent}"
}
#################
#
# For node2
#
File<<| title == '/etc/mynode.txt' |>>
#################
Do note that exporting and collecting resources depends on having [thin]
storeconfigs configured on the master. (Because, you know, the master
needs to store nodes' configurations to be able to use them to configure
other nodes.)
I should also say that although Puppet can do this job, it might not be the
most appropriate tool. You might want to consider alternative approaches,
such as (in no particular order)
- put the file under source control, such as in a git or Subversion
repository. Periodically sync any changes on node1 with the repository,
and periodically pull down any changes from the repository to node2.
- schedule a periodic direct copy from node1 to node2, via scp or some
similar remote copy tool
"Periodic[ally]" in the above is meant to imply use of an automated
scheduler, such as cron.
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/-/9EuGxiFZeOkJ.
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.
