Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
This issue is still unresolved as of 3.1.0
# hiera -h resources -c /etc/puppet/hiera.yaml
{webapplication2={Consumer=undef},
webapplication={Consumer={2a=nil, 1a={offset=3},
3a=undef}, indexer=nil}}
hieranil.pp
$fullhash = hiera_hash(resources)
create_resources(noundefparams,$fullhash)
define noundefparams($Consumer=abc, $indexer=def){
if $Consumer { notify {$Consumer:} }
}
_
]# puppet apply hieranil.pp
Error: Received incomplete information - no value provided for parameter
indexer at /tmp/experiment/hieranil.pp:15 on node puppet-master
Wrapped exception:
Received incomplete information - no value provided for parameter indexer
Error: Received incomplete information - no value provided for parameter
indexer at /tmp/experiment/hieranil.pp:15 on node puppet-master
On Thursday, May 24, 2012 3:15:58 AM UTC+5:30, Jeff McCune wrote:
On Tue, May 22, 2012 at 8:50 AM, Jeff McCune
je...@puppetlabs.comjavascript:
wrote:
On Tuesday, May 22, 2012, Dan White wrote:
I found an answer to this particular issue. Thanks for the reminder so
I can share the answer:
I found the hiera/yaml way to indicate an empty array !
So, to use my earlier example:
users:
beast:
username : beast
uid :
ingroups :
- ''
info : Let's see if this works
Then, with a hiera call, I get :
{beast={ingroups=[], uid=, username=beast,
info=Let's see if this works}
This is actually a non-empty array hat had one element, the empt string.
OK, I had a look today. Much of the behavior of hashes and arrays whose
elements are not defined has been resolved in Puppet 3.0.0rc. If you could
try that out it would help us make sure your problem has actually been
solved in Puppet.
As to how to specify an empty array as the value of a hash key using Hiera
and Puppet, this is the way:
---
username: beast
uid:
ingroups: []
info: Let's see if this works
Notice it's just an empty set of square braces, no empty string.
This clearly seems like a bug in puppet and how it is handling Hash
values. I'll take a look more as soon as I get into the office.
It is a bug, luckily we've fixed it in Puppet 3.0.x. Please give the
release candidates a try.
-Jeff
--
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+unsubscr...@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.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
Great !
Now all I need is some deep hash merging...
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
- Original Message -
From: Abhay chrungoo.ab...@gmail.com
To: puppet-users@googlegroups.com
Sent: Thursday, February 14, 2013 9:15:38 AM
Subject: Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
This issue is still unresolved as of 3.1.0
# hiera -h resources -c /etc/puppet/hiera.yaml
{webapplication2={Consumer=undef},
webapplication={Consumer={2a=nil, 1a={offset=3},
3a=undef}, indexer=nil}}
hieranil.pp
$fullhash = hiera_hash(resources)
create_resources(noundefparams,$fullhash)
define noundefparams($Consumer=abc, $indexer=def){
if $Consumer { notify {$Consumer:} }
}
_
]# puppet apply hieranil.pp
Error: Received incomplete information - no value provided for parameter
indexer at /tmp/experiment/hieranil.pp:15 on node puppet-master
Wrapped exception:
Received incomplete information - no value provided for parameter indexer
Error: Received incomplete information - no value provided for parameter
indexer at /tmp/experiment/hieranil.pp:15 on node puppet-master
On Thursday, May 24, 2012 3:15:58 AM UTC+5:30, Jeff McCune wrote:
On Tue, May 22, 2012 at 8:50 AM, Jeff McCune je...@puppetlabs.com wrote:
blockquote
On Tuesday, May 22, 2012, Dan White wrote:
blockquote
I found an answer to this particular issue. Thanks for the reminder so I can
share the answer:
I found the hiera/yaml way to indicate an empty array !
So, to use my earlier example:
users:
beast:
username : beast
uid :
ingroups :
- ''
info : Let's see if this works
Then, with a hiera call, I get :
{beast={ingroups=[], uid=, username=beast, info=Let's
see if this works}
This is actually a non-empty array hat had one element, the empt string.
/blockquote
OK, I had a look today. Much of the behavior of hashes and arrays whose
elements are not defined has been resolved in Puppet 3.0.0rc. If you could try
that out it would help us make sure your problem has actually been solved in
Puppet.
As to how to specify an empty array as the value of a hash key using Hiera and
Puppet, this is the way:
---
username: beast
uid:
ingroups: []
info: Let's see if this works
Notice it's just an empty set of square braces, no empty string.
blockquote
This clearly seems like a bug in puppet and how it is handling Hash values.
I'll take a look more as soon as I get into the office.
/blockquote
It is a bug, luckily we've fixed it in Puppet 3.0.x. Please give the release
candidates a try.
-Jeff
/blockquote
--
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+unsubscr...@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 .
--
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+unsubscr...@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.
Re: [Puppet Users] hiera questions
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
As far as I understood puppet is a config management system that configures
systems consistently over the enterprise based on facts and Hiera is a
hierarchical system that tells puppet whet the servers need
(or actually the other way arround, puppet looks up Hiera info).
Setting facts on a few servers is no problem, but what happens if you
manage several 100 servers? One of the primary goals for us in implementing
puppet/hiera was to avoid logins on servers. Every config change should NOT
happen on a server. A server must be completely replaceable. We never want
to come to a situation where we would have to look into a damaged server
trying to find out what custom roles were defined in it.
So, how do we solve this? We want to manage a server by just putting those
roles in hiera. If we want a server to do more we simply add a role. If we
need more servers to do more we create a new role, define what needs to be
done and add that role to the corresponding .yaml files.
so, a server on our hiera has something like:
roles:
- database
than it will load a file global/roles/database.yaml that has:
classes:
- mysql
This way our entire config is still in one place and we never have to do
any per server work. Just the way Puppet was originally designed (again,
as far as I understood).
best regards,
Alex
--
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/-/FzmHYCxLUqMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
This thought crossed our minds as well. I created the following feature request awhile back: https://projects.puppetlabs.com/issues/13934#change-60706 the intent behind which is if this fact is flagged as immutable, and it changes, something is drastically wrong… (don't)? do something until something along those lines is implemented, however, the following works reasonably well: the client/puppet master communication is wrapped around the base layer of trust of the ssl cert's CN. if you use that name to perform a lookup against an accessory lookup table before feeding hiera, this will accommodate most environments 'bootstrappy' needs… i.e.: certname: fooweb.product1.somesite.comhttp://fooweb.product1.somesite.com role: webserver tier: qa environment: product1 etc… your lookup table is outside of the client's control, so it cannot change these pieces of information. It also can not easily change it's certname… this provides a reasonable amount of security, and flexibility… I'd prefer to set a handful of facts that I know are 'correct' at system install time and not perform extra puppet master work at manifest compilation time, but that's just me. W On Jul 2, 2012, at 2:57 PM, Jan Ivar Beddari wrote: On 02. juli 2012 17:26, Darryl Wisneski wrote: modules I can use hiera to call up my hash and create ruby/puppet functions to do the server host location and functional logic based on the default facter facts of hostname and operatingsystem reported by the server host themselves. All the configuration remains in hiera and the module manifests remain puppet business logic. Comments? Off list as I'm too lazy to write in length and explain it all ;-) Do you care that the node (i.e root on the server) is able to say anything at all about its role and location? If you place a fact on the system that says what it is it could lie. What I'm getting at is security. I've designed my own hiera setup so that I don't use ANY host-derived facts, at all. The only thing I can be (relatively) sure of on the puppetmaster is that clientcert is what it says it is. In a multi-tenant scenario (or easier even, in a scenario where all your servers have a common root password) where would you place your source of truth? Don't know if you see this or care but still fired this off. best, Jan Ivar Beddari Linux/Mac architect University of Bergen, Norway -- http://www.uib.no/personer/Jan.Ivar.Beddari -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
On Thu, Jun 28, 2012 at 08:04:09PM +0100, R.I.Pienaar wrote:
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
Howdy:
I was wondering what is the best way to manage custom facts for a
disparate group of servers that need to report different fact values
for the same fact name? I am about to embark on hiera-based puppet
architecture and want to archetect it only once. I have some doubts
about the recommended ways of rolling out facter as it can get messy
burying facter server host configuration logic in disparate modules.
Let's say you want to create only one custom fact script to manage
all your facts based on data center location and functional server
host grouping. You decide you can manage all your custom facts
from one ruby/facter script if you create a ruby function using a
hash with your facter matching hostnames loaded in the hash as the
key and you can lookup location and function. Now you have to
choose which module to roll it from, but it's arbitrary.
Would one hash in a single custom facter script be enough configuration
for the all the hosts? I argue it would as you can add rows and
columns to the hash, so it should be able to support all your facter
needs. Either using custom facts or loading in all your hosts into
a hiera hash, you still have to know your hostnames.
However, why bury your custom facter script in a module with all
the configuration in there too? The current architecture and
directed use of facter alongside puppet/hiera seems to go against
the nature of moving your configuration out of manifests as the
direction of puppet/hiera is headed now.
I was thinking of creating a hiera hash or two (I am using YAML so
far. I could use as many hashes as required but one should be
enough probably, plus any arrays), including the information/configuration,
grouping servers by location and function, minimally. In my puppet
modules I can use hiera to call up my hash and create ruby/puppet
functions to do the server host location and functional logic based
on the default facter facts of hostname and operatingsystem reported
by the server host themselves. All the configuration remains in
hiera and the module manifests remain puppet business logic.
Comments?
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
On 02. juli 2012 17:26, Darryl Wisneski wrote: modules I can use hiera to call up my hash and create ruby/puppet functions to do the server host location and functional logic based on the default facter facts of hostname and operatingsystem reported by the server host themselves. All the configuration remains in hiera and the module manifests remain puppet business logic. Comments? Off list as I'm too lazy to write in length and explain it all ;-) Do you care that the node (i.e root on the server) is able to say anything at all about its role and location? If you place a fact on the system that says what it is it could lie. What I'm getting at is security. I've designed my own hiera setup so that I don't use ANY host-derived facts, at all. The only thing I can be (relatively) sure of on the puppetmaster is that clientcert is what it says it is. In a multi-tenant scenario (or easier even, in a scenario where all your servers have a common root password) where would you place your source of truth? Don't know if you see this or care but still fired this off. best, Jan Ivar Beddari Linux/Mac architect University of Bergen, Norway -- http://www.uib.no/personer/Jan.Ivar.Beddari -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
On 02. juli 2012 17:26, Darryl Wisneski wrote: Regards, -dkw Ouch, sorry Darryl, I hit the wrong button and posted what I thought of as a private very quick reply to you .. right on the list. Now at least everyone sees my honest-to-god thoughts on the matter. And the scope of the message becomes a bit more broad. Might even be worth starting a new thread. To the OP, sorry for being such a thread crasher. As to your question I think the answers you got are OK but hopefully you understand what caveats there might be security-wise. best, Jan Ivar -- http://www.uib.no/personer/Jan.Ivar.Beddari -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
On Mon, Jul 02, 2012 at 10:13:51PM +0200, Jan Ivar Beddari wrote: On 02. juli 2012 17:26, Darryl Wisneski wrote: Regards, -dkw Ouch, sorry Darryl, I hit the wrong button and posted what I thought of as a private very quick reply to you .. right on the list. Jan: I too am sorry I stole the thread. I had best intentions, alas I got carried away. I am interested in learning how you structured your hiera data and dealt with puppet code with the use of no/limited facts. The security point is well taken. At some point though, there has to be trust (obviously). General security best-practice considers mitigating procedures (such as IDS, file integrity monitoring (aide), and regular patching) your best attempt to avoid placing too much trust in the management tool. Regards, -dkw Now at least everyone sees my honest-to-god thoughts on the matter. And the scope of the message becomes a bit more broad. Might even be worth starting a new thread. To the OP, sorry for being such a thread crasher. As to your question I think the answers you got are OK but hopefully you understand what caveats there might be security-wise. best, Jan Ivar -- http://www.uib.no/personer/Jan.Ivar.Beddari -- 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
In regard to: Re: [Puppet Users] hiera questions, llow...@oreillyauto.com...:
On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote:
- Original Message -
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
That's simple enough, and the docs [1] for creating a custom fact are
mostly straightforward.
I would echo what others have said. Create some custom facts for
personalities or roles (and subroles, etc., if necessary) for your
systems, and have your hierarchy set to search based on those. We use:
:hierarchy: - secure/fqdn/%{clientcert}
- fqdn/%{clientcert}
- secure/location/%{location}
- location/%{location}
- secure/common
- common
Note that location is a custom fact for us, based on datacenter. You
could do something similar, just don't go crazy with the hierarchy levels.
The one thing I am unclear on, in the plugins in modules [2] document, it
says that if you are going to put your custom stuff in a module (such as in
their example, named 'custom') it says to follow the standard layout, and
that you have to have a manifests/init.pp.
If all that is actually in the thing is lib/facter/myfact.rb, what do I put
in the manifests/init.pp ? Is it enough for it to exist but be empty?
Yes it is.
You probably have some kind of base or our_site module already that
just does things like
include ntp
include admin_packages
include ssh
include syslog
etc. You could associate your custom fact(s) with that module by putting
them in the lib/facter directory for that module.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] hiera questions
I'm starting to use hiera more, to try to clean up and better modularize
some of our stuff.
I know you can use various facts (such as $::hostname) when defining the
hierarchy and where to look.
We have a few variables that are set based on patterns of hostname, and
currently we have a selector that matches the hostname against a regex.
Is there a clean way to move this to hiera? A straight %{hostname} in the
hiera.yaml won't work, since then I'd have to create a .yaml per hostname
and it'd be a hassle to
Say I have the hostnames setup like: prefix-purpose-[A-Z]-[0-9]+ where
prefix is a fixed value across all names, purpose describes whether it is a
web server, app server etc.
I'd like to be able to specify things for a given prefix-purpose-[A-Z]
range as well as on a prefix-purpose basis.
I do hope what I am asking is clear, if not I apologize.
--
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/-/u3bhvLZBz2sJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote:
- Original Message -
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
That's simple enough, and the docs [1] for creating a custom fact are
mostly straightforward.
The one thing I am unclear on, in the plugins in modules [2] document, it
says that if you are going to put your custom stuff in a module (such as in
their example, named 'custom') it says to follow the standard layout, and
that you have to have a manifests/init.pp.
If all that is actually in the thing is lib/facter/myfact.rb, what do I put
in the manifests/init.pp ? Is it enough for it to exist but be empty?
The document was somewhat unclear on this, or I missed it when reading.
[1] http://docs.puppetlabs.com/guides/custom_facts.html
[2] http://docs.puppetlabs.com/guides/plugins_in_modules.html
--
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/-/NKCt1qaRwiEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] hiera questions
You need your custom fact script in:
module/lib/facter/script
On 29/06/2012, at 7:37, llow...@oreillyauto.com llow...@oreillyauto.com
wrote:
On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote:
- Original Message -
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
That's simple enough, and the docs [1] for creating a custom fact are mostly
straightforward.
The one thing I am unclear on, in the plugins in modules [2] document, it
says that if you are going to put your custom stuff in a module (such as in
their example, named 'custom') it says to follow the standard layout, and
that you have to have a manifests/init.pp.
You need your custom fact script in:
module/lib/facter/script
If all that is actually in the thing is lib/facter/myfact.rb, what do I put
in the manifests/init.pp ? Is it enough for it to exist but be empty?
You would normally put your module definitions in init.pp but you should have
the following as a minimum:
class module name {
}
The document was somewhat unclear on this, or I missed it when reading.
[1] http://docs.puppetlabs.com/guides/custom_facts.html
[2] http://docs.puppetlabs.com/guides/plugins_in_modules.html
--
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/-/NKCt1qaRwiEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On 22/05/12 00:22, Jeff McCune wrote:
On Mon, May 21, 2012 at 1:24 AM, Luke Bigum luke.bi...@lmax.com
mailto:luke.bi...@lmax.com wrote:
I agree with Gary, Dan, it's probably the lack of data in the
'v_ingroups' key in your YAML that create_resources() is
complaining about. If it truly can't pass an empty key/val pair
you could do something hacky like use the string undef then
explicitly check for it in the define.
define add_virtual_user ( $v_username, $v_uid, $v_ingroups,
$v_info ) {
if ($v_ingroups == undef) {
Do you really mean to be comparing to the string undef rather than
the keyword undef (no quotes)?
Yes, unfortunately I did. It's because when using Hiera 0.3 it's a bit
difficult to figure out what a Ruby nil gets passed into Puppet as.
Consider the following manifest using Dan's example YAML (v_ingroups is
a nil value):
#---
#users:
# beast:
# v_username : beast
# v_uid :
# v_ingroups :
# v_info : Let's see if this works
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
notify { $name:
message = username = ${v_username}, uid = ${v_uid}, ingroups =
${v_ingroups}, info = ${v_info},
}
}
$the_users = hiera_hash('users')
notice($the_users[beast])
notice(prints as ${the_users[beast][v_ingroups]})
if ($the_users[beast][v_ingroups] == undef) {
notice(is == undef)
}
if (defined($the_users[beast][v_ingroups])) {
notice(is not defined)
}
if ($the_users[beast][v_ingroups] == ) {
notice(is empty string)
}
if (! $the_users[beast][v_ingroups]) {
notice(is false)
}
if ($the_users[beast][v_ingroups]) {
notice(is true)
}
if ($the_users[beast][v_ingroups] == nil) {
notice(is nil?)
}
create_resources('add_virtual_user', $the_users)
---
It's not an empty string, it's not undef (but when you print it it comes
out as undef), it's not nil (which doesn't exist in Puppet), it's not
false but it *is* true? I've came across this once before and can't
remember what nil actually gets interpreted as.
So if you feed that Puppet hash directly into the create_resources()
function, it complains about a missing parameter:
-
biguml@biguml-laptop:~$ puppet apply test.pp
notice: Scope(Class[main]):
v_usernamebeastv_uidv_ingroupsundefv_infoLet's see if this works
notice: Scope(Class[main]): undef
notice: Scope(Class[main]): is true
Must pass a parameter or all necessary values at /home/biguml/test.pp:40
on node biguml-laptop
-
So my suggestion was to explicitly set undef as a string in the yaml,
then match on that in the Puppet manifests. It's horrible but would work.
-Luke
There's a big difference...
If you want to test if a variable is undefined the best way is to do this:
if ($foo == undef) { notice \$foo is undef }
else { notice \$foo is defined as ${foo} }
-Jeff
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
LMAX operates a multilateral trading facility. Authorised and regulated
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809).
Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
I found an answer to this particular issue. Thanks for the reminder so I can
share the answer:
I found the hiera/yaml way to indicate an empty array !
So, to use my earlier example:
users:
beast:
username : beast
uid :
ingroups :
- ''
info : Let's see if this works
Then, with a hiera call, I get :
{beast={ingroups=[], uid=, username=beast, info=Let's
see if this works}
I was able to more forward past this problem after figuring that out.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
- Luke Bigum luke.bi...@lmax.com wrote:
On 22/05/12 00:22, Jeff McCune wrote:
On Mon, May 21, 2012 at 1:24 AM, Luke Bigum luke.bi...@lmax.com
mailto:luke.bi...@lmax.com wrote:
I agree with Gary, Dan, it's probably the lack of data in the
'v_ingroups' key in your YAML that create_resources() is
complaining about. If it truly can't pass an empty key/val pair
you could do something hacky like use the string undef then
explicitly check for it in the define.
define add_virtual_user ( $v_username, $v_uid, $v_ingroups,
$v_info ) {
if ($v_ingroups == undef) {
Do you really mean to be comparing to the string undef rather than
the keyword undef (no quotes)?
Yes, unfortunately I did. It's because when using Hiera 0.3 it's a bit
difficult to figure out what a Ruby nil gets passed into Puppet as.
Consider the following manifest using Dan's example YAML (v_ingroups is
a nil value):
#---
#users:
# beast:
# v_username : beast
# v_uid :
# v_ingroups :
# v_info : Let's see if this works
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
notify { $name:
message = username = ${v_username}, uid = ${v_uid}, ingroups =
${v_ingroups}, info = ${v_info},
}
}
$the_users = hiera_hash('users')
notice($the_users[beast])
notice(prints as ${the_users[beast][v_ingroups]})
if ($the_users[beast][v_ingroups] == undef) {
notice(is == undef)
}
if (defined($the_users[beast][v_ingroups])) {
notice(is not defined)
}
if ($the_users[beast][v_ingroups] == ) {
notice(is empty string)
}
if (! $the_users[beast][v_ingroups]) {
notice(is false)
}
if ($the_users[beast][v_ingroups]) {
notice(is true)
}
if ($the_users[beast][v_ingroups] == nil) {
notice(is nil?)
}
create_resources('add_virtual_user', $the_users)
---
It's not an empty string, it's not undef (but when you print it it comes
out as undef), it's not nil (which doesn't exist in Puppet), it's not
false but it *is* true? I've came across this once before and can't
remember what nil actually gets interpreted as.
So if you feed that Puppet hash directly into the create_resources()
function, it complains about a missing parameter:
-
biguml@biguml-laptop:~$ puppet apply test.pp
notice: Scope(Class[main]):
v_usernamebeastv_uidv_ingroupsundefv_infoLet's see if this works
notice: Scope(Class[main]): undef
notice: Scope(Class[main]): is true
Must pass a parameter or all necessary values at /home/biguml/test.pp:40
on node biguml-laptop
-
So my suggestion was to explicitly set undef as a string in the yaml,
then match on that in the Puppet manifests. It's horrible but would work.
-Luke
There's a big difference...
If you want to test if a variable is undefined the best way is to do this:
if ($foo == undef) { notice \$foo is undef }
else { notice \$foo is defined as ${foo} }
-Jeff
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On Tuesday, May 22, 2012, Dan White wrote:
I found an answer to this particular issue. Thanks for the reminder so I
can share the answer:
I found the hiera/yaml way to indicate an empty array !
So, to use my earlier example:
users:
beast:
username : beast
uid :
ingroups :
- ''
info : Let's see if this works
Then, with a hiera call, I get :
{beast={ingroups=[], uid=, username=beast,
info=Let's see if this works}
This is actually a non-empty array hat had one element, the empt string.
This clearly seems like a bug in puppet and how it is handling Hash values.
I'll take a look more as soon as I get into the office.
-Jeff
I was able to more forward past this problem after figuring that out.
“Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
- Luke Bigum luke.bi...@lmax.com javascript:; wrote:
On 22/05/12 00:22, Jeff McCune wrote:
On Mon, May 21, 2012 at 1:24 AM, Luke Bigum
luke.bi...@lmax.comjavascript:;
mailto:luke.bi...@lmax.com wrote:
I agree with Gary, Dan, it's probably the lack of data in the
'v_ingroups' key in your YAML that create_resources() is
complaining about. If it truly can't pass an empty key/val pair
you could do something hacky like use the string undef then
explicitly check for it in the define.
define add_virtual_user ( $v_username, $v_uid, $v_ingroups,
$v_info ) {
if ($v_ingroups == undef) {
Do you really mean to be comparing to the string undef rather than
the keyword undef (no quotes)?
Yes, unfortunately I did. It's because when using Hiera 0.3 it's a bit
difficult to figure out what a Ruby nil gets passed into Puppet as.
Consider the following manifest using Dan's example YAML (v_ingroups is
a nil value):
#---
#users:
# beast:
# v_username : beast
# v_uid :
# v_ingroups :
# v_info : Let's see if this works
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
notify { $name:
message = username = ${v_username}, uid = ${v_uid}, ingroups =
${v_ingroups}, info = ${v_info},
}
}
$the_users = hiera_hash('users')
notice($the_users[beast])
notice(prints as ${the_users[beast][v_ingroups]})
if ($the_users[beast][v_ingroups] == undef) {
notice(is == undef)
}
if (defined($the_users[beast][v_ingroups])) {
notice(is not defined)
}
if ($the_users[beast][v_ingroups] == ) {
notice(is empty string)
}
if (! $the_users[beast][v_ingroups]) {
notice(is false)
}
if ($the_users[beast][v_ingroups]) {
notice(is true)
}
if ($the_users[beast][v_ingroups] == nil) {
notice(is nil?)
}
create_resources('add_virtual_user', $the_users)
---
It's not an empty string, it's not undef (but when you print it it comes
out as undef), it's not nil (which doesn't exist in Puppet), it's not
false but it *is* true? I've came across this once before and can't
remember what nil actually gets interpreted as.
So if you feed that Puppet hash directly into the create_resources()
function, it complains about a missing parameter:
-
biguml@biguml-laptop:~$ puppet apply test.pp
notice: Scope(Class[main]):
v_usernamebeastv_uidv_ingroupsundefv_infoLet's see if this works
notice: Scope(Class[main]): undef
notice: Scope(Class[main]): is true
Must pass a parameter or all necessary values at /home/biguml/test.pp:40
on node biguml-laptop
-
So my suggestion was to explicitly set undef as a string in the yaml,
then match on that in the Puppet manifests. It's horrible but would work.
-Luke
There's a big difference...
If you want to test if a variable is undefined the best way is to do
this:
if ($foo == undef) { notice \$foo is undef }
else { notice \$foo is defined as ${foo} }
-Jeff
--
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@
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: An array of :datadir: ?
On 18/05/12 14:00, Dan White wrote:
Thanks for responding, Luke.
This looks like a useful expansion of the hiera back-end, but as I am still
fairly new to Puppet (and Python and Ruby for that matter), I think I will wait
for this to be formally accepted and incorporated before trying it myself.
One parting question: Is the :hierarchy: repeated in each mamber of the
:datadir: ? Logically, it should repeat, but I'd rather ask and be certain.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
Hi Dan,
Last week I was going to reply with Sure does, here's an example
debug... and I released that my code didn't work they way I thought it
did, I had the inner and outer loops around the wrong way ;-)
So after much more butchering of RIP's code I can happily report that
the :hierarchy: is searched as the outer loop, the :datadir: Array as
the inner loop. This means that first the %{fqdn} files are searched in
each member of :datadir:, then if nothing is found it moves on to
'%{lmax_env}_role' and so on down the hierarchy.
A (working!) example:
[root@gs2puppet01 ~]# /opt/ruby-enterprise/bin/hiera -c
/etc/puppet/hiera.yaml -y
/var/lib/puppet/yaml/facts/test.example.com.yaml -a collective --debug
DEBUG: Mon May 21 07:59:39 + 2012: Hiera JSON backend starting
DEBUG: Mon May 21 07:59:39 + 2012: Looking up collective in JSON backend
DEBUG: Mon May 21 07:59:39 + 2012: Looking for data source
test.example.com
DEBUG: Mon May 21 07:59:39 + 2012: Backend datadir for json is an
Array, multiple data dirs to search
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/private/test.example.com.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Found datafile
/etc/puppet/environments/production/hiera_data_store/test.example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/rebirth_data_store/test.example.com.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/satellite_system_groups/test.example.com.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Attempting to read JSON from
/etc/puppet/environments/production/hiera_data_store/test.example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Looking for data source _role
DEBUG: Mon May 21 07:59:39 + 2012: Backend datadir for json is an
Array, multiple data dirs to search
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/private/_role.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/hiera_data_store/_role.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/rebirth_data_store/_role.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/satellite_system_groups/_role.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Looking for data source _server
DEBUG: Mon May 21 07:59:39 + 2012: Backend datadir for json is an
Array, multiple data dirs to search
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/private/_server.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/hiera_data_store/_server.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/rebirth_data_store/_server.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/satellite_system_groups/_server.json, skipping
DEBUG: Mon May 21 07:59:39 + 2012: Looking for data source example.com
DEBUG: Mon May 21 07:59:39 + 2012: Backend datadir for json is an
Array, multiple data dirs to search
DEBUG: Mon May 21 07:59:39 + 2012: Found datafile
/etc/puppet/private/example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Found datafile
/etc/puppet/environments/production/hiera_data_store/example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/rebirth_data_store/example.com.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/environments/production/satellite_system_groups/example.com.json,
skipping
DEBUG: Mon May 21 07:59:39 + 2012: Attempting to read JSON from
/etc/puppet/private/example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Attempting to read JSON from
/etc/puppet/environments/production/hiera_data_store/example.com.json
DEBUG: Mon May 21 07:59:39 + 2012: Looking for data source common
DEBUG: Mon May 21 07:59:39 + 2012: Backend datadir for json is an
Array, multiple data dirs to search
DEBUG: Mon May 21 07:59:39 + 2012: Cannot find datafile
/etc/puppet/private/common.json, skipping
DEBUG: Mon
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On Mon, May 21, 2012 at 1:24 AM, Luke Bigum luke.bi...@lmax.com wrote:
I agree with Gary, Dan, it's probably the lack of data in the
'v_ingroups' key in your YAML that create_resources() is complaining about.
If it truly can't pass an empty key/val pair you could do something hacky
like use the string undef then explicitly check for it in the define.
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
if ($v_ingroups == undef) {
Do you really mean to be comparing to the string undef rather than the
keyword undef (no quotes)?
There's a big difference...
If you want to test if a variable is undefined the best way is to do this:
if ($foo == undef) { notice \$foo is undef }
else { notice \$foo is defined as ${foo} }
-Jeff
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: An array of :datadir: ?
On 18/05/12 04:04, Dan White wrote:
In a posting a few days ago was this hiera.yaml source listing:
-
:backends: - json
:hierarchy: - %{fqdn}
- %{lmax_role}_role
- %{lmax_env}_server
- %{pop}.tradefair
- common
:json:
:datadir: - /etc/puppet/private/
- /etc/puppet/environments/%{environment}/hiera_data_store/
- /etc/puppet/environments/%{environment}/rebirth_data_store/
- /etc/puppet/environments/%{environment}/satellite_system_groups/
-
I am curious how one might utilize this configuration.
Hi Dan,
That's my own terrible modifications to Hiera to support multiple data
stores of the same type. Code is here, but I warn you, I hacked in the
quickest way to get the functionality I wanted. I only modify
hiera-json, would be simple to do any others though:
https://github.com/lukebigum/hiera
https://github.com/lukebigum/hiera-json
As for use cases, a more elegant description is in this feature request:
http://projects.puppetlabs.com/issues/13954
Can the same key value appear in more than one datadir ?
Yes, but precedence is taken just like Hiera's natural hierarchy, so
data stores at the start of the array have higher priority. In my case
for example, hiera_data_store overrides satellite_system_groups.
Or does one use the multiple datadir's to group keys in some fashion ?
That was the the original idea of the hack - I had data coming from
several places - some JSON written by hand, some generated by scripts
(the 'satellite_system_groups' store is a dump of our old Red Hat
Satellite System Groups and 'rebirth_data_store' is procedurally
generated). I could have modified the generating scripts to read any
existing JSON and write out a merged file, but I was rushing and I
didn't think of that at the time ;-)
It has managed to keep a nice logical separation of types of Hiera keys
though and you can put your data stores in different locations, like
having a 'private' dir for password hashes that's not under revision
control. This leads to giving our Development team a Git repo that's the
lowest priority data store and allow them to specify their own keys to
configure their Dev servers. Any Admin still has the ability to
overwrite any key in an data store above it, so it stops them doing
anything silly like changing passwords, LDAP servers, etc, as these keys
will already be set by us (Admins).
-Luke
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
LMAX operates a multilateral trading facility. Authorised and regulated
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809).
Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
- Gary Larizza g...@puppetlabs.com wrote: On Thu, May 17, 2012 at 9:12 PM, Dan White y...@comcast.net wrote: One way I have seen for setting up system users is to create them virtually and then realize them with the spaceship operator, say by ggroup -- like this: User | groups == 'wheel' | Reference: http://www.mail-archive.com/puppet-users@googlegroups.com/msg29719.html In the referenced posting, the OP was trying to create a bunch of virtual users with all the parameter data in hiera. But this is usually done with create_resources and that don't do virtual :( So, I am asking a couple of questions going in different directions: Can anyone show me a way to create a virtual resource from hiera ? Actually, that should be: Hot to create a bunch of virtual resources from a hiera-hash Contrarywise, it was suggested in the referenced posting that one could find all users in all hierarchies with hiera_hash and then declare them at once. The down side of that is that using the spaceship operator, one can filter by class parameters and there is no problem if the same virtual resource is realized more than once. I am not certain that the hash-merge would produce a list of unique resource parameters. If the same user was in more than one hiera file, would it appear multiple times in the hash ? That's exactly what I was suggesting. If you declared the users as create_resources expected it, and included the same user in multiple levels of the hierarchy, the hash merging functionality would leave you with a single user declaration. One caveat (as of right now): you need to declare ALL the parameters in ALL the levels of the hierarchy. -- Ah, Gary ! Just the brain I wish to pick ! :) Thanks for the response. It makes sense. However, if I perceive this properly, it would provide an All-Or-Nothing implementation of users. I am looking for for a way to have a master list of users in hiera and then realize/instantiate a group-keyed-subset of the master list on each node. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On 18/05/12 13:46, Dan White wrote:
Ah, Gary ! Just the brain I wish to pick ! :)
Thanks for the response. It makes sense.
However, if I perceive this properly, it would provide an All-Or-Nothing
implementation of users.
I am looking for for a way to have a master list of users in hiera and then
realize/instantiate a group-keyed-subset of the master list on each node.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
Why not use a define to wrap the virtualised declaration of your users,
or tried and doesn't work? Theoretically like this:
define virtualise_user ($name, $uid, ...) {
@user { $name:
uid = $uid,
}
}
$all_users = hiera_hash('users')
create_resources('virtualise_user', $all_users)
-Luke
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
LMAX operates a multilateral trading facility. Authorised and regulated
by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809).
Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: An array of :datadir: ?
- Luke Bigum luke.bi...@lmax.com wrote:
On 18/05/12 04:04, Dan White wrote:
In a posting a few days ago was this hiera.yaml source listing:
-
:backends: - json
:hierarchy: - %{fqdn}
- %{lmax_role}_role
- %{lmax_env}_server
- %{pop}.tradefair
- common
:json:
:datadir: - /etc/puppet/private/
- /etc/puppet/environments/%{environment}/hiera_data_store/
- /etc/puppet/environments/%{environment}/rebirth_data_store/
-
/etc/puppet/environments/%{environment}/satellite_system_groups/
-
I am curious how one might utilize this configuration.
Hi Dan,
That's my own terrible modifications to Hiera to support multiple data
stores of the same type. Code is here, but I warn you, I hacked in the
quickest way to get the functionality I wanted. I only modify
hiera-json, would be simple to do any others though:
https://github.com/lukebigum/hiera
https://github.com/lukebigum/hiera-json
As for use cases, a more elegant description is in this feature request:
http://projects.puppetlabs.com/issues/13954
Can the same key value appear in more than one datadir ?
Yes, but precedence is taken just like Hiera's natural hierarchy, so
data stores at the start of the array have higher priority. In my case
for example, hiera_data_store overrides satellite_system_groups.
Or does one use the multiple datadir's to group keys in some fashion ?
That was the the original idea of the hack - I had data coming from
several places - some JSON written by hand, some generated by scripts
(the 'satellite_system_groups' store is a dump of our old Red Hat
Satellite System Groups and 'rebirth_data_store' is procedurally
generated). I could have modified the generating scripts to read any
existing JSON and write out a merged file, but I was rushing and I
didn't think of that at the time ;-)
It has managed to keep a nice logical separation of types of Hiera keys
though and you can put your data stores in different locations, like
having a 'private' dir for password hashes that's not under revision
control. This leads to giving our Development team a Git repo that's the
lowest priority data store and allow them to specify their own keys to
configure their Dev servers. Any Admin still has the ability to
overwrite any key in an data store above it, so it stops them doing
anything silly like changing passwords, LDAP servers, etc, as these keys
will already be set by us (Admins).
-Luke
Thanks for responding, Luke.
This looks like a useful expansion of the hiera back-end, but as I am still
fairly new to Puppet (and Python and Ruby for that matter), I think I will wait
for this to be formally accepted and incorporated before trying it myself.
One parting question: Is the :hierarchy: repeated in each mamber of the
:datadir: ? Logically, it should repeat, but I'd rather ask and be certain.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
- Luke Bigum luke.bi...@lmax.com wrote:
On 18/05/12 13:46, Dan White wrote:
Ah, Gary ! Just the brain I wish to pick ! :)
Thanks for the response. It makes sense.
However, if I perceive this properly, it would provide an All-Or-Nothing
implementation of users.
I am looking for for a way to have a master list of users in hiera and then
realize/instantiate a group-keyed-subset of the master list on each node.
“Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
Why not use a define to wrap the virtualised declaration of your users,
or tried and doesn't work? Theoretically like this:
define virtualise_user ($name, $uid, ...) {
@user { $name:
uid = $uid,
}
}
$all_users = hiera_hash('users')
create_resources('virtualise_user', $all_users)
The original posting tried it like this:
class users {
$system_users = hiera('system_users')
$system_groups = hiera('system_groups')
create_resources(@users::mkuser,$system_users)
create_resources(@users::mkgroup,$system_groups)
} # class users
... and puppet screamed could not create resource of unknown type
@users::mkuser
I can certainly try that and see what happens.
Thanks.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On Friday, May 18, 2012, jcbollinger wrote: On May 17, 11:16 pm, Gary Larizza g...@puppetlabs.com javascript:; wrote: That's exactly what I was suggesting. If you declared the users as create_resources expected it, and included the same user in multiple levels of the hierarchy, the hash merging functionality would leave you with a single user declaration. One caveat (as of right now): you need to declare ALL the parameters in ALL the levels of the hierarchy. That's because hiera hash merging is shallow, right? That is, every value in the resulting hash is the exact one given for the associated key at some level of the hierarchy? I'm not complaining; I just want to confirm that I understand correctly. Yep, Hiera doesn't currently support deep merges. John -- 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.comjavascript:; . To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com javascript:;. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
- Luke Bigum luke.bi...@lmax.com wrote:
On 18/05/12 13:46, Dan White wrote:
Ah, Gary ! Just the brain I wish to pick ! :)
Thanks for the response. It makes sense.
However, if I perceive this properly, it would provide an All-Or-Nothing
implementation of users.
I am looking for for a way to have a master list of users in hiera and then
realize/instantiate a group-keyed-subset of the master list on each node.
“Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
Why not use a define to wrap the virtualised declaration of your users,
or tried and doesn't work? Theoretically like this:
define virtualise_user ($name, $uid, ...) {
@user { $name:
uid = $uid,
}
}
$all_users = hiera_hash('users')
create_resources('virtualise_user', $all_users)
Closer, but no cigar yet !
user.pp:
-
define add_user ( $username, $uid, $ingroups, $info ) {
clip
}
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
@add_user { ${name}:
username = ${v_username},
uid = ${v_uid},
ingroups = ${v_ingroups},
info = ${v_info},
}
}
-
/etc/puppet/hierdata/common.yaml:
-
users:
beast:
v_username : beast
v_uid :
v_ingroups :
v_info : Let's see if this works
boo:
v_username : boo
v_uid : 6667
v_ingroups :
v_info : Let's see if this works also
-
And if I say:
hiera users -c /etc/puppet/hiera.yaml
I get:
{beast={v_info=Let's see if this works, v_username=beast,
v_ingroups=nil, v_uid=}, boo={v_info=Let's see if this works
also, v_username=boo, v_ingroups=nil, v_uid=6667}}
Which is out of order, but everything is there. That's how hashes are supposed
to work !
But when I try to run the catalog with
$the_users = hiera('users') or $the_users = hiera_hash('users')
followed by :
create_resources ( 'add_virtual_user', $the_users )
I get:
Must pass a parameter or all necessary values at
/etc/puppet/manifests/nodes/puppetmaster-node.pp:15 on node puppetmaster.foo.org
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
I wonder if the nil value is not being accepted as 'being passed' - can you
populate the nil value and try again?
On Fri, May 18, 2012 at 2:41 PM, Dan White y...@comcast.net wrote:
- Luke Bigum luke.bi...@lmax.com wrote:
On 18/05/12 13:46, Dan White wrote:
Ah, Gary ! Just the brain I wish to pick ! :)
Thanks for the response. It makes sense.
However, if I perceive this properly, it would provide an
All-Or-Nothing implementation of users.
I am looking for for a way to have a master list of users in hiera and
then realize/instantiate a group-keyed-subset of the master list on each
node.
“Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
Why not use a define to wrap the virtualised declaration of your users,
or tried and doesn't work? Theoretically like this:
define virtualise_user ($name, $uid, ...) {
@user { $name:
uid = $uid,
}
}
$all_users = hiera_hash('users')
create_resources('virtualise_user', $all_users)
Closer, but no cigar yet !
user.pp:
-
define add_user ( $username, $uid, $ingroups, $info ) {
clip
}
define add_virtual_user ( $v_username, $v_uid, $v_ingroups, $v_info ) {
@add_user { ${name}:
username = ${v_username},
uid = ${v_uid},
ingroups = ${v_ingroups},
info = ${v_info},
}
}
-
/etc/puppet/hierdata/common.yaml:
-
users:
beast:
v_username : beast
v_uid :
v_ingroups :
v_info : Let's see if this works
boo:
v_username : boo
v_uid : 6667
v_ingroups :
v_info : Let's see if this works also
-
And if I say:
hiera users -c /etc/puppet/hiera.yaml
I get:
{beast={v_info=Let's see if this works, v_username=beast,
v_ingroups=nil, v_uid=}, boo={v_info=Let's see if this
works also, v_username=boo, v_ingroups=nil, v_uid=6667}}
Which is out of order, but everything is there. That's how hashes are
supposed to work !
But when I try to run the catalog with
$the_users = hiera('users') or $the_users = hiera_hash('users')
followed by :
create_resources ( 'add_virtual_user', $the_users )
I get:
Must pass a parameter or all necessary values at
/etc/puppet/manifests/nodes/puppetmaster-node.pp:15 on node
puppetmaster.foo.org
“Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Hiera Questions: An array of :datadir: ?
In a posting a few days ago was this hiera.yaml source listing:
-
:backends: - json
:hierarchy: - %{fqdn}
- %{lmax_role}_role
- %{lmax_env}_server
- %{pop}.tradefair
- common
:json:
:datadir: - /etc/puppet/private/
- /etc/puppet/environments/%{environment}/hiera_data_store/
- /etc/puppet/environments/%{environment}/rebirth_data_store/
- /etc/puppet/environments/%{environment}/satellite_system_groups/
-
I am curious how one might utilize this configuration.
Can the same key value appear in more than one datadir ?
Or does one use the multiple datadir's to group keys in some fashion ?
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Hiera Questions: Virtual User Resources and Hiera
One way I have seen for setting up system users is to create them virtually and then realize them with the spaceship operator, say by ggroup -- like this: User | groups == 'wheel' | Reference: http://www.mail-archive.com/puppet-users@googlegroups.com/msg29719.html In the referenced posting, the OP was trying to create a bunch of virtual users with all the parameter data in hiera. But this is usually done with create_resources and that don't do virtual :( So, I am asking a couple of questions going in different directions: Can anyone show me a way to create a virtual resource from hiera ? Actually, that should be: Hot to create a bunch of virtual resources from a hiera-hash Contrarywise, it was suggested in the referenced posting that one could find all users in all hierarchies with hiera_hash and then declare them at once. The down side of that is that using the spaceship operator, one can filter by class parameters and there is no problem if the same virtual resource is realized more than once. I am not certain that the hash-merge would produce a list of unique resource parameters. If the same user was in more than one hiera file, would it appear multiple times in the hash ? -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Hiera Questions: Virtual User Resources and Hiera
On Thu, May 17, 2012 at 9:12 PM, Dan White y...@comcast.net wrote: One way I have seen for setting up system users is to create them virtually and then realize them with the spaceship operator, say by ggroup -- like this: User | groups == 'wheel' | Reference: http://www.mail-archive.com/puppet-users@googlegroups.com/msg29719.html In the referenced posting, the OP was trying to create a bunch of virtual users with all the parameter data in hiera. But this is usually done with create_resources and that don't do virtual :( So, I am asking a couple of questions going in different directions: Can anyone show me a way to create a virtual resource from hiera ? Actually, that should be: Hot to create a bunch of virtual resources from a hiera-hash Contrarywise, it was suggested in the referenced posting that one could find all users in all hierarchies with hiera_hash and then declare them at once. The down side of that is that using the spaceship operator, one can filter by class parameters and there is no problem if the same virtual resource is realized more than once. I am not certain that the hash-merge would produce a list of unique resource parameters. If the same user was in more than one hiera file, would it appear multiple times in the hash ? That's exactly what I was suggesting. If you declared the users as create_resources expected it, and included the same user in multiple levels of the hierarchy, the hash merging functionality would leave you with a single user declaration. One caveat (as of right now): you need to declare ALL the parameters in ALL the levels of the hierarchy. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
