Howdy: I need some help please to get hiera configuration data derived from YAML, thru puppet. I have studied Internet search results and puppet documentation on create_resources and custom defines but need a little help along. I can print out the YAML from variables, arrays, and, finally, hashes too from a puppet manifest. One thing that is stumping me is how to access from the custom define only the YAML element of server-a which is I believe is an object of an array of hashes as I have the YAML laid out. When I run this on client host server-a against the manifest this prints out in the log: Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) setting sshd_type: local Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-b])) setting sshd_type: local Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-c])) setting sshd_type: local Aug 17 12:59:09 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-d])) setting sshd_type: local I want it to print out just server-a''s value. How do I do that? Also, interestingly, it printed out each of the server names (keys?) in the hash but the value of the server-a''s sshd_auth entry. My YAML, puppet manifest and error follow. # cat common.yaml --- searchdomain : ''example.com'' ssh_auth : ldap servers : server-a : sshd_auth: "local" ClientAliveInterval: "nil" ClientAliveCountMax: "nil" server-b : sshd_auth: "local" ClientAliveInterval: "nil" ClientAliveCountMax: "nil" server-c : sshd_auth: "ldap" ClientAliveInterval: "nil" ClientAliveCountMax: "nil" server-d : sshd_auth: "ldap" ClientAliveInterval: "10" ClientAliveCountMax: "3" # cat ../hiera.yaml --- :backends: - yaml :logger: console :hierarchy: - %{hostname} - common :yaml: :datadir: /usr/local/etc/puppet/hieradata # cat Inuit.pp class user { $sshd_hash = hiera(servers) create_resources(''sshd_lookup'', $sshd_hash) } define sshd_lookup ( $sshd_auth, $ClientAliveInterval, $ClientAliveCountMax, $server_role, $location ) { $data = hiera_hash(''servers'') $sshd_type = $data[$hostname][''sshd_auth''] notice ("setting sshd_type: $sshd_type" ) } Thanks, Regards, -dkw -- 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.
On Friday, August 17, 2012 12:08:41 PM UTC-5, dkw wrote:> > Howdy: > > I need some help please to get hiera configuration data derived > from YAML, thru puppet. I have studied Internet search results and > puppet documentation on create_resources and custom defines but > need a little help along. I can print out the YAML from variables, > arrays, and, finally, hashes too from a puppet manifest. > > One thing that is stumping me is how to access from the custom > define only the YAML element of server-a which is I believe is an > object of an array of hashes as I have the YAML laid out. > > When I run this on client host server-a against the manifest this prints > out in the log: > > Aug 17 12:59:09 puppet puppet-master[67407]: > (Scope(Sshd_lookup[server-a])) setting sshd_type: local > Aug 17 12:59:09 puppet puppet-master[67407]: > (Scope(Sshd_lookup[server-b])) setting sshd_type: local > Aug 17 12:59:09 puppet puppet-master[67407]: > (Scope(Sshd_lookup[server-c])) setting sshd_type: local > Aug 17 12:59:09 puppet puppet-master[67407]: > (Scope(Sshd_lookup[server-d])) setting sshd_type: local > > I want it to print out just server-a''s value. How do I do that? >Your focus on what is printed to the log is a bit confusing. To the extent that you are using the log output to track what Puppet is doing it''s fine, but if your main objective is to extract data from YAML then there are far, *far* less convoluted ways to go about it.> Also, interestingly, it printed out each of the server names (keys?) > in the hash but the value of the server-a''s sshd_auth entry. >Not that interesting, really. Puppet is just doing what you told it to do. See below.> > My YAML, puppet manifest and error follow. > > # cat common.yaml > --- > searchdomain : ''example.com'' > ssh_auth : ldap > servers : > server-a : > sshd_auth: "local" > ClientAliveInterval: "nil" > ClientAliveCountMax: "nil" > server-b : > sshd_auth: "local" > ClientAliveInterval: "nil" > ClientAliveCountMax: "nil" > server-c : > sshd_auth: "ldap" > ClientAliveInterval: "nil" > ClientAliveCountMax: "nil" > server-d : > sshd_auth: "ldap" > ClientAliveInterval: "10" > ClientAliveCountMax: "3" > >[...]> > # cat Inuit.pp > class user { > $sshd_hash = hiera(servers) > create_resources(''sshd_lookup'', $sshd_hash) >In answer to your first question, about declaring only an sshd_lookup resource for server-a, you apparently have a key misunderstanding about create_resources(). That function creates one resource of the specified type for *each* top-level key in the provided hash. The keys are used as the resource titles, and the values are hashes of parameter key/value pairs for the corresponding resource instance. If you only want an sshd_lookup resource for server-a, then either you must feed it a hash containing only an entry for server-a, or else you must declare the sshd_lookup in the conventional way. For example, instead of the create_resources() call above, use: $server_a_params = $sshd_hash[''server-a''] sshd_lookup { ''server-a'': sshd_auth => $server_a_params[''sshd_auth''], ClientAliveInterval => $server_a_params[''ClientAliveInterval''], ClientAliveCountMax => $server_a_params[''ClientAliveCountMax''] } Alternatively, you could construct a single-entry hash of hashes of the correct form for create_resources(); I leave that as an exercise.> > } > > define sshd_lookup ( $sshd_auth, $ClientAliveInterval, > $ClientAliveCountMax, > $server_role, $location ) { > > $data = hiera_hash(''servers'') > $sshd_type = $data[$hostname][''sshd_auth''] >There, you are looking up an entry in the hash by the $hostname of the client for which you are compiling the catalog. For any given node, that will result in the same piece of data for every sshd_lookup instance. If you want the value appropriate for the current resource instance then you can either add $sshd_type to the parameter list (since you are otherwise just re-reading the same data that you passed to create_resources()), or else use $name or $title (they are equivalent in this context) to look up the desired entry in the outer hash. ($name and $title in a type definition refer to the title of the resource instance).> > notice ("setting sshd_type: $sshd_type" ) > > } > >Does that help? 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/-/5Iak2tlXMq8J. 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 Friday, August 17, 2012 4:36:13 PM UTC-5, jcbollinger wrote:> > > <snip> > > Does that help? > >I don''t know how much it will help the OP, but this has been a great help to me. I''ve never quite been able to figure out the create_resource thing, but I think I understand it now and what I was doing wrong. Thank you.> > 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/-/zjYazVmQURcJ. 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.
Darryl Wisneski
2012-Aug-20 16:32 UTC
Re: [Puppet Users] Re: Hiera, Hashes, and Create_resources
Hi John: Thanks for your comments and instruction. More inline... On Fri, Aug 17, 2012 at 02:36:13PM -0700, jcbollinger wrote:> > # cat common.yaml > > --- > > searchdomain : ''example.com'' > > ssh_auth : ldap > > servers : > > server-a : > > sshd_auth: "local" > > ClientAliveInterval: "nil" > > ClientAliveCountMax: "nil" > > server-b : > > sshd_auth: "local" > > ClientAliveInterval: "nil" > > ClientAliveCountMax: "nil" > > server-c : > > sshd_auth: "ldap" > > ClientAliveInterval: "nil" > > ClientAliveCountMax: "nil" > > server-d : > > sshd_auth: "ldap" > > ClientAliveInterval: "10" > > ClientAliveCountMax: "3" > > > > > [...] > > > > > > # cat Inuit.pp > > class user { > > $sshd_hash = hiera(servers) > > create_resources(''sshd_lookup'', $sshd_hash) > > > > In answer to your first question, about declaring only an sshd_lookup > resource for server-a, you apparently have a key misunderstanding about > create_resources(). That function creates one resource of the specified > type for *each* top-level key in the provided hash. The keys are used as > the resource titles, and the values are hashes of parameter key/value pairs > for the corresponding resource instance. > > If you only want an sshd_lookup resource for server-a, then either you must > feed it a hash containing only an entry for server-a, or else you must > declare the sshd_lookup in the conventional way. For example, instead of > the create_resources() call above, use: > > $server_a_params = $sshd_hash[''server-a''] > sshd_lookup { ''server-a'': > sshd_auth => $server_a_params[''sshd_auth''], > ClientAliveInterval => $server_a_params[''ClientAliveInterval''], > ClientAliveCountMax => $server_a_params[''ClientAliveCountMax''] > }I would like to use a hash in conventional way, however, I can''t get that data from a YAML file with puppet DSL, so I understand. Should I try go down the road of using ruby DSL and a init.rb for my manifest, so I can lookup $hostname from client node directly from the YAML? The goal is to get all configuration data from one YAML file or database, abstracting the modules/manifest code.> > Alternatively, you could construct a single-entry hash of hashes of the > correct form for create_resources(); I leave that as an exercise.I did get a single YAML hash of hashes to work using hiera and create_resources, where the common.yaml file took over if a $name.yaml (or $hostname.yaml) file didn''t exist. That is not my requirement, unfortunately. I want to stuff all my server host information into the hash of hashes inside the YAML file, with the $hostname being the key.> > > > > > } > > > > define sshd_lookup ( $sshd_auth, $ClientAliveInterval, > > $ClientAliveCountMax, > > $server_role, $location ) { > > > > $data = hiera_hash(''servers'') > > $sshd_type = $data[$hostname][''sshd_auth''] > > > > There, you are looking up an entry in the hash by the $hostname of the > client for which you are compiling the catalog. For any given node, that > will result in the same piece of data for every sshd_lookup instance. > > If you want the value appropriate for the current resource instance then > you can either add $sshd_type to the parameter list (since you are > otherwise just re-reading the same data that you passed to > create_resources()), or else use $name or $title (they are equivalent in > this context) to look up the desired entry in the outer hash. ($name and > $title in a type definition refer to the title of the resource instance).Can you please illustrate looking up the desired entry in the outer hash? I have tried many ways and failed in all of them. This is probably the best way to do it. It''s data is derived from hiera and create_resource? Though inefficient and maybe not scalable depending on how big the hash becomes, I tried a conditional based on $name given the results of all the keys returned from create_resources and it works as I want it to: class user { $sshd_hash = hiera(servers) create_resources(''sshd_lookup'', $sshd_hash) } define sshd_lookup ( $sshd_auth, $ClientAliveInterval, $ClientAliveCountMax, $server_role, $location ) { $data = hiera_hash(''servers'') $sshd_type = $data[$name][''sshd_auth''] if $hostname == $name { notice "my name is $name" notice ("setting name: $name" ) notice ("setting hostname: $hostname" ) notice ("setting sshd_type: $sshd_type" ) # add machine logic #if ($sshd_type = ldap) { # include ldap #} #if ${clientaliverinterval} != nil { #augeas { "clientinterval_modify": #context => "/files/etc/ssh/sshd_config", #changes => "set ClientAliveInterval=${clientaliverinterval}"; #} } } Aug 20 12:19:47 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) my name is server-a Aug 20 12:19:47 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) setting name: server-a Aug 20 12:19:47 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) setting hostname: server-a Aug 20 12:19:47 puppet puppet-master[67407]: (Scope(Sshd_lookup[server-a])) setting sshd_type: local Many Thanks, -dkw> > > > > > > notice ("setting sshd_type: $sshd_type" ) > > > > } > > > > > Does that help? > > > 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/-/5Iak2tlXMq8J. > 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.
jcbollinger
2012-Aug-27 15:10 UTC
Re: [Puppet Users] Re: Hiera, Hashes, and Create_resources
On Monday, August 20, 2012 11:32:46 AM UTC-5, dkw wrote:> > Hi John: > > Thanks for your comments and instruction. More inline... > > On Fri, Aug 17, 2012 at 02:36:13PM -0700, jcbollinger wrote: > > > # cat common.yaml > > > --- > > > searchdomain : ''example.com'' > > > ssh_auth : ldap > > > servers : > > > server-a : > > > sshd_auth: "local" > > > ClientAliveInterval: "nil" > > > ClientAliveCountMax: "nil" > > > server-b : > > > sshd_auth: "local" > > > ClientAliveInterval: "nil" > > > ClientAliveCountMax: "nil" > > > server-c : > > > sshd_auth: "ldap" > > > ClientAliveInterval: "nil" > > > ClientAliveCountMax: "nil" > > > server-d : > > > sshd_auth: "ldap" > > > ClientAliveInterval: "10" > > > ClientAliveCountMax: "3" > > > > > > > > [...] > > > > > > > > > > # cat Inuit.pp > > > class user { > > > $sshd_hash = hiera(servers) > > > create_resources(''sshd_lookup'', $sshd_hash) > > > > > > > In answer to your first question, about declaring only an sshd_lookup > > resource for server-a, you apparently have a key misunderstanding about > > create_resources(). That function creates one resource of the specified > > type for *each* top-level key in the provided hash. The keys are used > as > > the resource titles, and the values are hashes of parameter key/value > pairs > > for the corresponding resource instance. > > > > If you only want an sshd_lookup resource for server-a, then either you > must > > feed it a hash containing only an entry for server-a, or else you must > > declare the sshd_lookup in the conventional way. For example, instead > of > > the create_resources() call above, use: > > > > $server_a_params = $sshd_hash[''server-a''] > > sshd_lookup { ''server-a'': > > sshd_auth => $server_a_params[''sshd_auth''], > > ClientAliveInterval => > $server_a_params[''ClientAliveInterval''], > > ClientAliveCountMax => $server_a_params[''ClientAliveCountMax''] > > } > > > I would like to use a hash in conventional way, however, I can''t get > that data from a YAML file with puppet DSL, so I understand.The "conventional way" is to use a standard resource declaration instead of create_resources(). I guess you really mean you want to use create_resources() to declare only one resource. As I described before, to achieve that the hash paramerter you pass to create_resources() must be contain a single key ("server-a") whose associated value is a hash associating each non-default parameter with its assigned value. If your data are structured appropriately for then you can get the needed hash directly or nearly directly from hiera. In particular, the ordinary hiera() function will return a hash if that''s the type of value associated with the requested key. If you want each node to have its own sshd-auth info, and no node needs to have any of the others'' info, then your data are structured sub-optimally. Node-specific data for different nodes should not generally be co-mingled, nor mixed with shared data. You already have a node-specific level in your hierarchy, so put the needed data there. You could continue to structure it as a hash mapped to a single key, but I would consider just raising the inner keys to the top level, and then using an ordinary resource declaration instead of create_resources(). Any way around, you certainly can build hashes in Puppet DSL, including with use of data obtained via hiera. For example, to obtain the hash you want from the data structure you already have, you should be able to do something like this: $sshd_lookup_data = { "${hostname}" => $sshd_hash["${hostname}"] }> Should > I try go down the road of using ruby DSL and a init.rb for my > manifest, so I can lookup $hostname from client node directly from > the YAML? The goal is to get all configuration data from one YAML > file or database, abstracting the modules/manifest code. >You do not need Ruby DSL to achieve your stated aim, and you should avoid Ruby DSL wherever you don''t need it. Hiera can do this job for you, or if you need something custom then I would suggest writing a custom Puppet function (in Ruby) instead of switching to Ruby DSL. I am confused, however. You say that you want all the data in a single file, yet you declare two levels in your Hiera hierarchy, one of them defined per-hostname. Do you just mean you want this particular data all in one file? (Why?) I think it will help you to decouple data source from data usage in your mind. That will align your thinking better with Hiera, as such decoupling / abstraction is the most fundamental aspect of what Hiera does for you in practice. So no, you don''t need your manifest to read data from a YAML file; instead, you need it to declare resources of particular types (e.g. Sshd_lookup) based on external data structured in some particular way. As a separate question, you need to configure Hiera and the data sources on which it will rely to define the needed data with the appropriate structure. Moreover, it is usually better to choose data structure based on the needs of your manifests where that is feasible, rather than deciding data structure a priori and having to develop manifests that are adapted for it. Either approach is doable, but usually it is easier to adapt the data structure to the needs of the manifests than the other way around.> > > > > Alternatively, you could construct a single-entry hash of hashes of the > > correct form for create_resources(); I leave that as an exercise. > > I did get a single YAML hash of hashes to work using hiera and > create_resources, where the common.yaml file took over if a $name.yaml > (or $hostname.yaml) file didn''t exist. That is not my requirement, > unfortunately. I want to stuff all my server host information into > the hash of hashes inside the YAML file, with the $hostname being > the key. >See above.> > > > > > > > > > > } > > > > > > define sshd_lookup ( $sshd_auth, $ClientAliveInterval, > > > $ClientAliveCountMax, > > > $server_role, $location ) { > > > > > > $data = hiera_hash(''servers'') > > > $sshd_type = $data[$hostname][''sshd_auth''] > > > > > > > There, you are looking up an entry in the hash by the $hostname of the > > client for which you are compiling the catalog. For any given node, > that > > will result in the same piece of data for every sshd_lookup instance. > > > > If you want the value appropriate for the current resource instance then > > you can either add $sshd_type to the parameter list (since you are > > otherwise just re-reading the same data that you passed to > > create_resources()), or else use $name or $title (they are equivalent in > > this context) to look up the desired entry in the outer hash. ($name > and > > $title in a type definition refer to the title of the resource > instance). > > Can you please illustrate looking up the desired entry in the outer > hash? I have tried many ways and failed in all of them. This is > probably the best way to do it.I will illustrate that momentarily. I suggest, however, that the best way to do it is almost certainly the other alternative I suggested; i.e. something like this: define sshd_lookup ( $sshd_auth, $ClientAliveInterval, $ClientAliveCountMax, $server_role, $location, $sshd_type ) { notice ("setting sshd_type: $sshd_type" ) } I''m rather surprised you''re not doing that already. Supposing that there is some reason you haven''t told us why you want to look up the data directly in the hash that was already loaded, here is how you would do it: define sshd_lookup ( $sshd_auth, $ClientAliveInterval, $ClientAliveCountMax, $server_role, $location ) { # ensure class User is loaded because we # want to use one of its variables include ''user'' $sshd_type = $user::data[$name][''sshd_type''] notice ("setting sshd_type: $sshd_type" ) }> It''s data is derived from hiera > and create_resource? > > Though inefficient and maybe not scalable depending on how big the > hash becomes, I tried a conditional based on $name given the results > of all the keys returned from create_resources and it works as I > want it to: > > class user { > $sshd_hash = hiera(servers) > create_resources(''sshd_lookup'', $sshd_hash) > } > > define sshd_lookup ( $sshd_auth, $ClientAliveInterval, > $ClientAliveCountMax, > $server_role, $location ) { > > $data = hiera_hash(''servers'') > $sshd_type = $data[$name][''sshd_auth''] > > if $hostname == $name { > > notice "my name is $name" > notice ("setting name: $name" ) > notice ("setting hostname: $hostname" ) > notice ("setting sshd_type: $sshd_type" ) > > # add machine logic > #if ($sshd_type = ldap) { > # include ldap > #} > > #if ${clientaliverinterval} != nil { > #augeas { "clientinterval_modify": > #context => "/files/etc/ssh/sshd_config", > #changes => "set > ClientAliveInterval=${clientaliverinterval}"; > #} > } > > } > >Note that your conditional is absolutely pointless as far as the manifests you have presented to us go. You already know that the condition will always be satisfied if you declare only the one Sshd_lookup instance you want for a given node, because that''s the way you have structured the definition and its data. Furthermore, you may be approaching this altogether the wrong way. If it is part of the nature of sshd_lookup that no node will ever need to declare more than one instance, then sshd_lookup should probably be a class instead of a definition: class sshd_lookup { $all_data = hiera_hash(''servers'') $node_data = $all_data[$hostname] $sshd_auth = $node_data[''sshd_auth''] $ClientAliveInterval = $node_data[''ClientAliveInterval''] $ClientAliveCountMax = $node_data[''ClientAliveCountMax''] $server_role = $node_data[''server_role''] $location = $node_data[''location''] $sshd_type = $data[$hostname][''sshd_auth''] # ... } All things considered, I think you should take a step back and look at the bigger picture. You seem to be getting mired in the details. I''m not sure whether you inherited this from someone else, whether you have requirements you''re not telling us about, or what, but your overall design doesn''t seem all that solid. 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/-/BgWWfncIiF8J. 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.
Darryl Wisneski
2013-Feb-06 21:26 UTC
Re: [Puppet Users] Re: Hiera, Hashes, and Create_resources
On Mon, Aug 27, 2012 at 08:10:34AM -0700, jcbollinger wrote:> > > > # cat common.yaml > > > > --- > > > > searchdomain : ''example.com'' > > > > ssh_auth : ldap > > > > servers : > > > > server-a : > > > > sshd_auth: "local" > > > > ClientAliveInterval: "nil" > > > > ClientAliveCountMax: "nil" > > > > server-b : > > > > sshd_auth: "local" > > > > ClientAliveInterval: "nil" > > > > ClientAliveCountMax: "nil" > > > > server-c : > > > > sshd_auth: "ldap" > > > > ClientAliveInterval: "nil" > > > > ClientAliveCountMax: "nil" > > > > server-d : > > > > sshd_auth: "ldap" > > > > ClientAliveInterval: "10" > > > > ClientAliveCountMax: "3" > > > >> Furthermore, you may be approaching this altogether the wrong way. If it > is part of the nature of sshd_lookup that no node will ever need to declare > more than one instance, then sshd_lookup should probably be a class instead > of a definition:> > class sshd_lookup { > > $all_data = hiera_hash(''servers'') > $node_data = $all_data[$hostname] > > $sshd_auth = $node_data[''sshd_auth''] > $ClientAliveInterval = $node_data[''ClientAliveInterval''] > $ClientAliveCountMax = $node_data[''ClientAliveCountMax''] > $server_role = $node_data[''server_role''] > $location = $node_data[''location''] > $sshd_type = $data[$hostname][''sshd_auth''] > > # ... > } >Hi: I''ve been in a hole for while now and my puppet setup was working (albeit, very inefficiently and harder to read) until I upgraded recently, to puppet 3.0.x, so I came back to this thread. This approach of getting the entire hash out of the YAML via hiera from a class (as detailed above) instead of a defined type solved my problem and is much more elegant. I am still configuring all my hosts in a single YAML file Hash of Hashes (HoH). You questioned the approach and here it is: 1.) All hosts are in the node default 2.) The node default calls a single master module which parses the YAML HoH based on the facter hostname and performs role logic in puppet DSL and calls every other necessary module/manifest as the roles dictate. Every node is fully defined for every variable in the YAML file. Only this module should have configuration data in it. I suppose it could use ruby DSL if we wanted to here also. node default --> master_module w/ YAML HOH lookup and role logic --> other modules (dns, ssh, ldap, sudo) The only other module/manifest I haven''t been able to remove configuration data from is local ssh users, ssh keys etc. I suppose I could place users and ssh keys in another YAML file of structured data. Thanks, -dkw> > John-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.