export a file from a node to another node

[Nikolaos Hatzopoulos]

So let's say you have two nodes
node1 and node2

node1 has a text file with one line saying in /etc/mynode.txt:

node1

how you receive this information and pass it to node2 using puppet?

--Nikos

[jcbollinger]

 
The standard means for nodes to publish information to the master is via facts, and the standard means for the master to use information belonging to one node to configure another node is exporting and collecting resources.  In principle, therefore, you create a custom fact by which node2 (and every other node) publishes the contents of /etc/mynode.txt to the master, and the master creates an exported resource such as this:

@@file { "/etc/nodes/${hostname}-mynode.txt":
  # using your custom fact:
  content => "${mynode_txt_content}"
}

Among the classes assigned to node2, at least one would collect some or all of those files:

# This actually collects *all* exported files:
File<<| |>>

Node2 would then get copies of all nodes' /etc/mynode.txt files as /etc/nodes/<nodename>-mynodes.txt.


John

[Nikolaos Hatzopoulos]

so we define that file would be exported from node1 like:

@@file { "etc/mynode.txt:":
   content => "${mycontent}"
}

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

--Nikos

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

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[jcbollinger]

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

[Nikolaos Hatzopoulos]

as far as I understand for files you need a unique title in my case /etc/mynodes.txt

how you can export instead of a file a variable and let's say it has a unique "title"
and it has as content a string can you do that?

The scp won't work because I am trying to setup the ssh keys with taking the key
from a specific node and putting into the authorized_keys file of the other :) on the other
hand I can make the scp for the root user.. but if you do that what's the point of using
puppet (i have only linux nodes)?

--Nikos

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

[jcbollinger]

On Thursday, July 26, 2012 10:41:28 AM UTC-5, Nikolaos Hatzopoulos wrote:

as far as I understand for files you need a unique title in my case /etc/mynodes.txt

how you can export instead of a file a variable and let's say it has a unique "title"
and it has as content a string can you do that?

You can only export resources, not variables.  You can, however, export resources of any type, including custom and defined types.  I'm not quite following what you don't like about the approach I've selected so far, but most objectives of this kind can be realized by exporting and collecting resources of some type, if you really want or need to go through Puppet as the intermediary.
 

The scp won't work because I am trying to setup the ssh keys with taking the key
from a specific node and putting into the authorized_keys file of the other :) on the other
hand I can make the scp for the root user.. but if you do that what's the point of using
puppet (i have only linux nodes)?

Not this, actually.  Puppet's main purpose is to serve as a central authority and manager for the configuration of nodes under its purview.  Copying data from one node to another is conflicts with "central authority" because it makes the source node the authority for the information copied.  If you want Puppet only for this purpose, then you probably don't really want Puppet at all.

A solution more in the Puppet style would be to generate all the keys on the master (possibly, but not necessarily, inside Puppet), and have Puppet distribute them to all parties that need them.


John

[Nikolaos Hatzopoulos]

My philosophy is that if you implement something would be easy to redo it and produce
a new key, kind of something nice that puppet has, so the thing that you are suggesting
with the export it sounds complicated and I wanted to learn what it does because I
saw it was a new feature,  but as I see it is better to be centralize and produce
the keys on the server and distribute them to the nodes.

thanks for the responds,
--Nikos

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

[Stuart Cracraft]

Puppet is worth it just for mere dint of the fact of centralized control of SSH keys 

Go Puppet go!

--Stuart

Via Apple iPhone 4S on the AT&T Wireless Network

[thijso]

I distribute my root keys through the following setup:

A custom fact ('ssh_pub_keys.rb') exports my root pub keys. Then I include the 'dasar::ssh_keys::root' class on my nodes (see 'root.pp'). Now I can ssh from all my machines that have that include into all my other machines that have it too.

If you want to get fancy, you could leave the last statement out of that class, and do specific collects in your node defs, like:

node satu {
  Ssh_authorized_key <<| tag == "ssh_authorized_key-root_dua" |>>
}

node dua {
  Ssh_authorized_key <<| tag == "ssh_authorized_key-root_satu" |>>
}

node tiga {
  Ssh_authorized_key <<| |>>
}

Now satu and dua can only get into each other, and tiga can get on all of them.

Thijs

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

[thijso]

Uh, crap. Should include the files of course. Here they are...