Re: [Puppet Users] exporting custom facts to puppet agents
Yes, the file is only on the master (and not exactly maintained by the Puppet but the provisioning framework) and it looks something like this: Slackware, Linux, i-num=1 Jaguar, MacX, i-num=6 Chicago, this_Win, i-num=2 Daytona, an_other_Win, i-num=7 RedHat, Linux, i-num=5 Lion, MacY, i-num=4 Caldera, Linux, i-num=9 Longhorn, that_Win, i-num=8 Tiger, MacZ, i-num=3 Indiana, Solaris, i-num=10 Kodiak, MacX, i-num=11 What I was trying to do is to get a fact (or function) that returns a string like: win,mac,linux, as I showed in my previous post. Really appreciate if you can make an example function out of that. cheers!! On Monday, October 14, 2013 9:37:51 PM UTC+1, Cristian Falcas wrote: i understood that the file is only on the master? If so, I will try to write something tomorrow to implement this, If the value never changes, it will be better to put it in an external variable. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] pypuppetdb 0.0.4 / puppetboard 0.0.2
Hello everyone, It's been way to long since the release but I finally had some time to sort a few things out and release updates to both pypuppetdb and Puppetboard. For those of you who have no idea what this is about: * pypuppetdb is a library to work with the PuppetDB API in Python; * Puppetboard is meant as a replacement to Puppet Dashboard leveraging PuppetDB through pypuppetdb as its datasource. New is PuppetDB 1.5 (API v3) compatibility. None of the new features of API v3 have been implemented yet, that's going to be the goal for the coming weeks but everything that used to be possible with API v2 + Experimental is now available over API v3. Because PuppetDB 1.5 dropped the /experimental endpoints those have been removed from pypuppetdb too, even for older versions of PuppetDB. Puppetboard has gained a metrics tab and facts now have pretty pie-charts as well as an assorted set of small fixes and improvement across the board. Once pypuppetdb has gained support for all the new features in API v3 there are going to be some significant changes to Puppetboard, both in its capabilities and the UI. For those of you who will be at Puppet Camp London in November, I'm hoping I'll be able to show you at least some of that. As usual you can get the code from: * pypuppetdb: https://github.com/nedap/pypuppetdb or `pip install pypuppetdb` * puppetboard: https://github.com/nedap/puppetboard -- Daniele Sluijters -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Sync data between various PuppetDB instances
Ok, so I finally opted for inserting a full node from one DB into
another, since getting the resources should be quite easy with a GET.
But then I run into a problem when running the replace catalog command
(with an empty catalog):
curl -vv -G -H Accept: application/json
'http://localhost:8080/v2/commands' --data-urlencode
'payload={command:replace catalog,version: 2,payload:{
\metadata\: {\api_version\: 1}, \data\: {\name\:
\puppet09.cscs.ch\,\version\: \\, \edges\: [],
\resources\: [] }}}'
Which returns ok. The puppetdb.log shows:
2013-10-15 10:42:02,060 ERROR [command-proc-45] [puppetdb.command]
[43c41752-e7d4-4725-b062-7b3a9b1ac8ec] [replace catalog] Retrying after
attempt 8, due to: org.postgresql.util.PSQLException: ERROR: syntax
error at or near )
Position: 66
I have looked again and again into the data, and syntax seems to be correct.
Anybody tried this? Hints?
Thanks a lot,
Pablo Fernandez
On 10/10/2013 05:23 PM, Throwe, Jesse wrote:
That would really depend on the approach ultimately taken for the
multi-master. If the puppet master (or agent in masterless mode)
forwards the same fact/report/node/etc data to multiple puppetdb
instances then yes the scale breaks horribly and does not meet part of
this request. If there is some kind of store-and-forward mechanism in
puppetdb itself, it would be possible to extend the forward to say
'only if it matches these rules'. This could definitely be useful in
a variety of ways beyond simple HA purposes.
On Thu, Oct 10, 2013 at 11:07 AM, Pablo Fernandez
pablo.fernan...@cscs.ch mailto:pablo.fernan...@cscs.ch wrote:
Yes, I saw that... this may be a solution for replicating full
PuppetDBs (if you tackle the backlog during a long shortage), but
that does not scale very well if you have 5-10 PuppetDBs all being
replicated to a single, bigger one.
Besides, it would not cover cases when you want to have only some
nodes replicated, or even only some resources.
On 10/10/2013 04:35 PM, Throwe, Jesse wrote:
It sounds like a shade of #19321 -
https://projects.puppetlabs.com/issues/19321
On Thu, Oct 10, 2013 at 10:31 AM, Wolf Noble w...@wolfspyre.com
mailto:w...@wolfspyre.com wrote:
I'd be interested in accomplishing a similar thing. I want to
have a central reporting puppetdb which I can (outside of
puppet) query for multisite information without tying
isolated environments together via a single postgres db, or
using multi-master replication.
my needs do not involve making each puppet site aware of each
other's data, but it would be nice to have one db which has
all the data for my digging pleasure.
from my understanding this is not currently supported.
I was thinking something could be done to ask puppetdb at
site A (what updates have you had in the past N minutes/
since the last time I checked in with you/ since
timestamp(N)), and then iterate through the collected data
and feed it into a reporting puppetdb instance, however I've
not gone beyond thinking about it.
On Thu, Oct 10, 2013 at 7:12 AM, Pablo Fernandez
pablo.fernan...@cscs.ch mailto:pablo.fernan...@cscs.ch wrote:
Thanks Ken,
I took a look at the Command API and seems to be quite
interesting, but
it triggers a few more questions.
As a reminder (also for others), what I wanted to do was
to add exported
resources from Node_A (managed by PuppetMaster_A that has
its own
PuppetDB_A) into a different PuppetDB_B, where Node_A is
unknown, in
order for other Nodes_B (managed by PuppetMaster_B) be
aware and
possibly realize those exported resources.
Taking a look the Commands API seem to capabilities to
change a whole
catalog, or facts. Do they need to be existing catalogs,
or could I add
new ones?
I am thinking: If I want to add Node_A's exported
resource(s) to
PuppetDB_B, I could artificially add its whole catalog to
PuppetDB_B... but the Command API is replace catalog,
no add
catalog. Would it be rejected? How does the first
catalog of a node get
introduced into the DB? And moreover, how do I query a
whole catalog?
Another possibility would be to include the resource
inside an existing
Node_B catalog on the PuppetDB_B (after all, exported
resources don't
really mater what node do they belong, as long as they
have the right
attributes, right?), but the Catalog wire format seems to
require the
Re: [Puppet Users] Sync data between various PuppetDB instances
If I try to add a fictitious resource:
{\type\: \Service\,
\title\: \iptables\,
\exported\: false,
\file\: \/etc/puppet/modules/puppetdb/manifests/server.pp\,
\line\: 121,
\tags\: [\node\, \puppetdb\],
\parameters\: {
\ensure\ : \running\}
}
I get:
2013-10-15 11:20:43,042 ERROR [command-proc-45] [puppetdb.command]
[15abcd55-b7c6-4acc-8839-94b96f85ba68] [replace catalog] Retrying after
attempt 8, due to: org.postgresql.util.PSQLException: No value specified
for parameter 1.
This way of issuing commands is quite nasty...
BR/Pablo
On 10/15/2013 11:00 AM, Pablo Fernandez wrote:
Ok, so I finally opted for inserting a full node from one DB into
another, since getting the resources should be quite easy with a GET.
But then I run into a problem when running the replace catalog command
(with an empty catalog):
curl -vv -G -H Accept: application/json
'http://localhost:8080/v2/commands' --data-urlencode
'payload={command:replace catalog,version: 2,payload:{
\metadata\: {\api_version\: 1}, \data\: {\name\:
\puppet09.cscs.ch\,\version\: \\, \edges\: [],
\resources\: [] }}}'
Which returns ok. The puppetdb.log shows:
2013-10-15 10:42:02,060 ERROR [command-proc-45] [puppetdb.command]
[43c41752-e7d4-4725-b062-7b3a9b1ac8ec] [replace catalog] Retrying
after attempt 8, due to: org.postgresql.util.PSQLException: ERROR:
syntax error at or near )
Position: 66
I have looked again and again into the data, and syntax seems to be
correct.
Anybody tried this? Hints?
Thanks a lot,
Pablo Fernandez
On 10/10/2013 05:23 PM, Throwe, Jesse wrote:
That would really depend on the approach ultimately taken for the
multi-master. If the puppet master (or agent in masterless mode)
forwards the same fact/report/node/etc data to multiple puppetdb
instances then yes the scale breaks horribly and does not meet part
of this request. If there is some kind of store-and-forward
mechanism in puppetdb itself, it would be possible to extend the
forward to say 'only if it matches these rules'. This could
definitely be useful in a variety of ways beyond simple HA purposes.
On Thu, Oct 10, 2013 at 11:07 AM, Pablo Fernandez
pablo.fernan...@cscs.ch mailto:pablo.fernan...@cscs.ch wrote:
Yes, I saw that... this may be a solution for replicating full
PuppetDBs (if you tackle the backlog during a long shortage), but
that does not scale very well if you have 5-10 PuppetDBs all
being replicated to a single, bigger one.
Besides, it would not cover cases when you want to have only some
nodes replicated, or even only some resources.
On 10/10/2013 04:35 PM, Throwe, Jesse wrote:
It sounds like a shade of #19321 -
https://projects.puppetlabs.com/issues/19321
On Thu, Oct 10, 2013 at 10:31 AM, Wolf Noble w...@wolfspyre.com
mailto:w...@wolfspyre.com wrote:
I'd be interested in accomplishing a similar thing. I want
to have a central reporting puppetdb which I can (outside of
puppet) query for multisite information without tying
isolated environments together via a single postgres db, or
using multi-master replication.
my needs do not involve making each puppet site aware of
each other's data, but it would be nice to have one db which
has all the data for my digging pleasure.
from my understanding this is not currently supported.
I was thinking something could be done to ask puppetdb at
site A (what updates have you had in the past N minutes/
since the last time I checked in with you/ since
timestamp(N)), and then iterate through the collected data
and feed it into a reporting puppetdb instance, however I've
not gone beyond thinking about it.
On Thu, Oct 10, 2013 at 7:12 AM, Pablo Fernandez
pablo.fernan...@cscs.ch mailto:pablo.fernan...@cscs.ch
wrote:
Thanks Ken,
I took a look at the Command API and seems to be quite
interesting, but
it triggers a few more questions.
As a reminder (also for others), what I wanted to do was
to add exported
resources from Node_A (managed by PuppetMaster_A that
has its own
PuppetDB_A) into a different PuppetDB_B, where Node_A is
unknown, in
order for other Nodes_B (managed by PuppetMaster_B) be
aware and
possibly realize those exported resources.
Taking a look the Commands API seem to capabilities to
change a whole
catalog, or facts. Do they need to be existing catalogs,
or could I add
new ones?
I am thinking: If I want to add Node_A's exported
resource(s) to
PuppetDB_B, I could artificially add its whole catalog to
PuppetDB_B... but the
Re: [Puppet Users] Re: Duplicate declaration for files.
Just my 2 cents... is better if you use stdlib - concat function for
/etc/hosts... you can have a default section for all the hosts and a
customized one for specific cases. You avoid conflicts as well.
Cheers
On Monday, October 14, 2013 4:28:39 PM UTC+1, mike wrote:
Hello,
I fix the problem with a case statement:
[...]
class baseos::rhel-hosts {
case $fqdn {
'new-node.example.com': {
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
source =
puppet:///modules/baseos/new-node/hosts,
}
}
default: {
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
ensure = file,
source =
puppet:///modules/baseos/hosts,
mode = 644,
}
}
}
}
[...]
Thanks.
2013/10/14 jcbollinger john.bo...@stjude.org javascript:
On Friday, October 11, 2013 11:24:44 AM UTC-5, mike wrote:
Hello,
I'm configuring my linux server with puppet open and is ok. My question
is the next; I've a declared in mi nodes.pp the next:
[.]
node 'basenode' {
include 'baseos'
include 'motd'
import 'useradd.pp'
}
#All nodes for my domain
node /.*\.example\.com/ inherits basenode {
}
[.]
All nodes inherit basenode, Inside the class baseos i've declared the
archive host table and various other parameters
[.]
file { /etc/hosts:
ensure = present,
owner = root,
group = root,
mode= '664',
source = puppet:///modules/baseos/**hosts,
}
[.]
But I need add other node in nodes.pp and this need apply the class
baseos but without /etc/hots because this use other hosts table that I
declared as follows:
[.]
node 'newnode.example.com' inherits basenode {
file { /etc/hosts:
ensure = file,
source = puppet:///modules/baseos/**newnode/hosts,
mode = 644,
}
}
[.]
But when I go newnode and run puppet give error for duplicate
/etc/hosts declaration
[.]
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Duplicate declaration: File[/etc/hosts] is already declared in file
/etc/puppet/modules/baseos/**manifests/config.pp:21; cannot redeclare
at /etc/puppet/manifests/nodes.**pp:55 on node newnode.example.com
[.]
How I can assign different tables hosts for different nodes in this case?
You need to do one of these things
- modify your baseos class so that it does not manage /etc/hosts on
those nodes where you want to specify a different hosts file (and perhaps
not on *any* node), or
- modify your baseos class so that it manages /etc/hosts correctly
for all nodes, and stop re-declaring that file in node blocks, or
- stop assigning class baseos to those nodes for which it declares
the wrong /etc/hosts content (relying only on node blocks or on a
different
class in those cases).
Implicit in all of the above is this:do not assign a class to a node if
you don't want all the resources it declares. (There is a last-ditch
workaround for that, but it would cause you more harm than good at your
level of Puppet experience.)
There are multiple ways to go about those, but I hesitate to suggest
specifics without understanding why the new node is an exception to your
general rule.
John
--
You received this message because you are subscribed to a topic in the
Google Groups Puppet Users group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/puppet-users/Yw62zu_VhhY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
puppet-users...@googlegroups.com javascript:.
To post to this group, send email to puppet...@googlegroups.comjavascript:
.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are
Re: [Puppet Users] Re: External Facts on Windows with Powershell
Ticket updated :) -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Sync data between various PuppetDB instances
Hehe, sorry for the auto-reply... but I made it work, and I wanted to
post it for reference.
The key was to add also the edges: it can't be an empty list.
For the record, doing:
# curl -vv -G -H Accept: application/json
'http://localhost:8080/v2/commands' --data-urlencode 'payload={
command: replace catalog,
version: 2,
payload: {
\metadata\: {
\api_version\: 1
},
\data\: {
\name\: \myhost.blabla.bla\,
\version\: \\,
\edges\: [
{\source\: {\type\: \Service\, \title\: \iptables\},
\target\: {\type\: \Service\, \title\: \iptables\},
\relationship\: \before\}
],
\resources\: [
{\type\: \Service\,
\title\: \iptables\,
\exported\: false,
\file\: \/etc/puppet/modules/puppetdb/manifests/server.pp\,
\line\: 121,
\tags\: [\node\, \puppetdb\],
\parameters\: {\hasrestart\: true, \ensure\ : \running\}
}
]
}
}
}'
Works like a charm, and add a new host into the PuppetDB out of the blue.
Next: automatically serialize those escaped quotes and try to see if it
exported resources work as they should.
Thanks, and sorry again for the noise,
BR/Pablo
On 10/15/2013 11:25 AM, Pablo Fernandez wrote:
If I try to add a fictitious resource:
{\type\: \Service\,
\title\: \iptables\,
\exported\: false,
\file\: \/etc/puppet/modules/puppetdb/manifests/server.pp\,
\line\: 121,
\tags\: [\node\, \puppetdb\],
\parameters\: {
\ensure\ : \running\}
}
I get:
2013-10-15 11:20:43,042 ERROR [command-proc-45] [puppetdb.command]
[15abcd55-b7c6-4acc-8839-94b96f85ba68] [replace catalog] Retrying
after attempt 8, due to: org.postgresql.util.PSQLException: No value
specified for parameter 1.
This way of issuing commands is quite nasty...
BR/Pablo
On 10/15/2013 11:00 AM, Pablo Fernandez wrote:
Ok, so I finally opted for inserting a full node from one DB into
another, since getting the resources should be quite easy with a GET.
But then I run into a problem when running the replace catalog
command (with an empty catalog):
curl -vv -G -H Accept: application/json
'http://localhost:8080/v2/commands' --data-urlencode
'payload={command:replace catalog,version: 2,payload:{
\metadata\: {\api_version\: 1}, \data\: {\name\:
\puppet09.cscs.ch\,\version\: \\, \edges\: [],
\resources\: [] }}}'
Which returns ok. The puppetdb.log shows:
2013-10-15 10:42:02,060 ERROR [command-proc-45] [puppetdb.command]
[43c41752-e7d4-4725-b062-7b3a9b1ac8ec] [replace catalog] Retrying
after attempt 8, due to: org.postgresql.util.PSQLException: ERROR:
syntax error at or near )
Position: 66
I have looked again and again into the data, and syntax seems to be
correct.
Anybody tried this? Hints?
Thanks a lot,
Pablo Fernandez
On 10/10/2013 05:23 PM, Throwe, Jesse wrote:
That would really depend on the approach ultimately taken for the
multi-master. If the puppet master (or agent in masterless mode)
forwards the same fact/report/node/etc data to multiple puppetdb
instances then yes the scale breaks horribly and does not meet part
of this request. If there is some kind of store-and-forward
mechanism in puppetdb itself, it would be possible to extend the
forward to say 'only if it matches these rules'. This could
definitely be useful in a variety of ways beyond simple HA purposes.
On Thu, Oct 10, 2013 at 11:07 AM, Pablo Fernandez
pablo.fernan...@cscs.ch mailto:pablo.fernan...@cscs.ch wrote:
Yes, I saw that... this may be a solution for replicating full
PuppetDBs (if you tackle the backlog during a long shortage),
but that does not scale very well if you have 5-10 PuppetDBs all
being replicated to a single, bigger one.
Besides, it would not cover cases when you want to have only
some nodes replicated, or even only some resources.
On 10/10/2013 04:35 PM, Throwe, Jesse wrote:
It sounds like a shade of #19321 -
https://projects.puppetlabs.com/issues/19321
On Thu, Oct 10, 2013 at 10:31 AM, Wolf Noble
w...@wolfspyre.com mailto:w...@wolfspyre.com wrote:
I'd be interested in accomplishing a similar thing. I want
to have a central reporting puppetdb which I can (outside
of puppet) query for multisite information without tying
isolated environments together via a single postgres db, or
using multi-master replication.
my needs do not involve making each puppet site aware of
each other's data, but it would be nice to have one db
which has all the data for my digging pleasure.
from my understanding this is not currently supported.
I was thinking something could be done to ask puppetdb at
site A (what updates have you had in the past N minutes/
since the last time I checked in with you/ since
timestamp(N)), and then iterate through the
Re: [Puppet Users] exporting custom facts to puppet agents
Put in $your_module_name/lib/puppet/parser/functions/am_running_oss.rb
module Puppet::Parser::Functions
newfunction(:am_running_oss, :type = :rvalue ) do |args|
#inFile = /tmp/OSs.txt
inFile = args[0]
gos = {}
if File.exist?(inFile)
open(inFile, 'r').each do |line|
next if line =~ /^\s*(#|$)/
parts = line.split(',').map(:strip)
case parts[1]
when /^Mac/
(gos[:mac] ||= []) parts[0]
#gos['1']
when /_Win$/
(gos[:win] ||= []) parts[0]
else
(gos[:linux] ||= []) parts[0]
end
end
end
if gos.count = 1
return gos.keys.join(',')
else
return 'undefined'
end
end
end
And from your module:
$q=am_running_oss(/tmp/OSs.txt)
notify { ${q}:}
Also, you could skip the parameter and just hard coded in the file.
On Tue, Oct 15, 2013 at 9:03 AM, Sans r.santanu@gmail.com wrote:
Yes, the file is only on the master (and not exactly maintained by the
Puppet but the provisioning framework) and it looks something like this:
Slackware, Linux, i-num=1
Jaguar, MacX, i-num=6
Chicago, this_Win, i-num=2
Daytona, an_other_Win, i-num=7
RedHat, Linux, i-num=5
Lion, MacY, i-num=4
Caldera, Linux, i-num=9
Longhorn, that_Win, i-num=8
Tiger, MacZ, i-num=3
Indiana, Solaris, i-num=10
Kodiak, MacX, i-num=11
What I was trying to do is to get a fact (or function) that returns a string
like: win,mac,linux, as I showed in my previous post. Really appreciate if
you can make an example function out of that. cheers!!
On Monday, October 14, 2013 9:37:51 PM UTC+1, Cristian Falcas wrote:
i understood that the file is only on the master? If so, I will try to
write something tomorrow to implement this,
If the value never changes, it will be better to put it in an external
variable.
--
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.
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Status of Data in modules
- Original Message - From: jcbollinger john.bollin...@stjude.org To: puppet-users@googlegroups.com Sent: Tuesday, October 15, 2013 2:08:10 PM Subject: Re: [Puppet Users] Re: Status of Data in modules On Tuesday, October 15, 2013 12:52:39 AM UTC-5, David Schmitt wrote: On 14.10.2013 16:16, jcbollinger wrote: So the proposed solution at this point is: - enable an implicit data-binding lookup against the hiera-puppet backend for a value of 'classname::variable' in the file 'modules/classname/manifests/params.pp', which simplifies class definition and provides consistency with other hiera backends. As a module author, you'd still leave your logic for variables in params.pp, but they'd be implicitly looked up via data bindings as the class is declared, after consulting site-wide hiera. Do I understand correctly that you set out to get rid of the ::params class pattern, but now you favor an approach that depends on that pattern? Why is that better than being more general: enable an implicit lowest-priority hierarchy level for values of form 'modulename::variable', drawing on data from per-module data files such as modules/modulename/data.yaml? AIUI, prototyping revealed that many params classes contain logic that cannot be expressed in .yaml to calculate default values. Making the fallback lookup check the params class, the logic can be preserved while avoiding verbose boilerplate code like the params_lookup calls in Alessandro's modules. I'm not saying that categorically getting rid of ::params classes is a viable target. In fact, I don't really understand why it was ever an objective in the first place. On the other hand, I don't see why it makes sense for Puppet to give special significance to that pattern, either. A more general data-in-modules feature such as I describe would give users the option to avoid ::params classes in some cases, and I'm inclined to think that it would be easier to implement, to understand, and to use. there are many reasons to avoid params.pp. It's *code* not *data* and it's one file that tends to include data for many different roles/sources/uses. You have to consider the main reasons for separating data from code in order to understand the motivation. When you have a params.pp you end up with stuff like this: https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/params.pp#L28-140 No-one would call that maintainable or readable vs say having AIX.json, Debian.json and so forth. For a community member who wants to add support for a new OS this simplifies things a LOT. They can see what operating systems are supported already and they can easily add a new one by dropping a single file. This improves the contributor life cycle significantly: * Adding FooOS support will not break existing supported OS support. FooOS.json is only going to be read on FooOS machines. * They do not have to worry about complex merge conflicts on busy modules such as the ones you'd find internal to large companies vs many team members editing a single param.pp * There's no syntax and stuff to bother about, its pretty easy evaluate the data and to pre/post commit check this stuff. Contributor dont have to test extensively to ensure he didnt accidentally mess up params.pp complex nested statements in some subtle manner * In large environments if you have strict change control etc, the previous points help things a lot, you can easily reason about the implications and you can be sure they wont affect existing systems. It's just data that will affect a small subset users. This improves the maintainers life because: * They can find it easier to merge new OS support because the change is contained in seperate files and easy to evaluate * Fewer complex merge commits and easier, cleaner, commit history * The code is simpler and generally easier to maintain in the long term This improves the module user life because: * He can just look at existing data files and know without having to parse complex nested case statements what the available overridable data is and what the keys would be etc. There are more but these are the basics From a Puppet system perspective its important that this feature behave consistently and predictably with the current more or less universally accepted standard of data seperation - hiera. And hiera is all about data, the hiera puppet backend has been broken for ages and not been missed because it does not provide a solution that solves the above points. And so the data separation around params.pp will not solve the real problems either. Data simply should not be mixed with logic - because then it becomes code again with all the related problems. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To
Re: [Puppet Users] Facter incorrectly detecting Virtual status on Windows VM
I created an issue. Never done one before so I may have balls it up a bit. I added you as a watcher Wasn't sure how to even properly begin with a pull request. I've barely used Git so the proper process of pulling and merging is out of my skill set right now. On Wednesday, October 9, 2013 2:51:09 PM UTC-6, Rob Reynolds wrote: Would you mind filing a pull request on this? If you already have please ignore. If you don't feel comfortable with that, please file an issue with the code you used to fix it and we will take a look at it. Thanks! On Tue, Oct 8, 2013 at 3:49 PM, Jason Harmon jharmo...@gmail.comjavascript: wrote: Ran into a problem with Facter on a Windows 2008 R2 system running on a proxmox server. Facter reports the machine as being physical. This is due to the WMI query used in the virtual.rb file is being return Bochs as the Manufacturer and Model. Adding an additional When statement to the Ruby file (virtual.rb) corrected the check coming back as physical. -- 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...@googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- Rob Reynolds Developer, Puppet Labs Join us at PuppetConf 2014, September 23-24 in San Francisco -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Facter incorrectly detecting Virtual status on Windows VM
Noticed that a matching issue was opened a few days ago, so I marked the one I opened as duplicate and just added a comment on the open issue instead. On Tuesday, October 15, 2013 9:11:42 AM UTC-6, Jason Harmon wrote: I created an issue. Never done one before so I may have balls it up a bit. I added you as a watcher Wasn't sure how to even properly begin with a pull request. I've barely used Git so the proper process of pulling and merging is out of my skill set right now. On Wednesday, October 9, 2013 2:51:09 PM UTC-6, Rob Reynolds wrote: Would you mind filing a pull request on this? If you already have please ignore. If you don't feel comfortable with that, please file an issue with the code you used to fix it and we will take a look at it. Thanks! On Tue, Oct 8, 2013 at 3:49 PM, Jason Harmon jharmo...@gmail.com wrote: Ran into a problem with Facter on a Windows 2008 R2 system running on a proxmox server. Facter reports the machine as being physical. This is due to the WMI query used in the virtual.rb file is being return Bochs as the Manufacturer and Model. Adding an additional When statement to the Ruby file (virtual.rb) corrected the check coming back as physical. -- 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...@googlegroups.com. To post to this group, send email to puppet...@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- Rob Reynolds Developer, Puppet Labs Join us at PuppetConf 2014, September 23-24 in San Francisco -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Could not find terminus puppetsvr for indirection catalog
I had a working puppet server and added the Dashboard. Then I got the inventory part of dashboard working. Now I've got what looks like one last error I can't get past: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find terminus mabospuppet01 for indirection catalog Any idea what this means or where I can get better error messages? I realize you need more info to better help diagnose - please let me know what I can provide. Server is Ubuntu precise with all patches. Puppet -v = 3.3.1 ruby -v = 1.8.7. Clients are talking to the server and I'm getting info in dashboard for inventory - even new clients that don't receive the catalog... Thank you, Todd -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find terminus puppetsvr for indirection catalog
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find terminus puppetsvr for indirection catalog I had a working puppet install (new) with 2 agents working well. I added puppet dashboard and the inventory part which is also working well. However, clients are talking to the server (putting info into dashboard inventory), but not pulling down the catalog. New clients give an error (no catalog) and existing clients reapply a cached catalog. Puppet version is 3.3.1. Server is Ubuntu 12.04 (precise). I realize that error isn't much to go on, but I can't seem to find any better error message to track down. What other information can I offer? thank you, Todd -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find terminus puppetsvr for indirection catalog
Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 400 on SERVER: Could not retrieve facts for mabosthoule-m2: Could not find terminus puppetsvr for indirection facts error changed from catalog to facts.. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet Enterprise 3.1 is now available
Hello puppet-users, We're pleased to announce that Puppet Enterprise 3.1 is immediately available for download: http://puppetlabs.com/misc/pe-files/ This latest release introduces the Puppet Enterprise event inspector, a new reporting tool that identifies what changed, where and how in your environment through the visual inspection of changes by classes, nodes and resources. Additional new capabilities in Puppet Enterprise 3.1 include: * Discoverable classes and parameters: Use the Puppet Enterprise GUI to inventory all the classes you're using in your infrastructure, then apply them to nodes and edit their parameters. * Google Compute Engine (GCE) provisioning: Stand up GCE cloud infrastructure by automatically provisioning, classifying and configuring nodes. * Windows reboot management: Configure automatic rebooting of Windows upon pending reboot system requests and the installation of new packages. * RHEL 4.0 support: Puppet Enterprise 3.1 adds RHEL 4.0 to existing support for RHEL 5.0 and 6.0, as well as Microsoft Windows, AIX, Solaris, Debian, Ubuntu, and more. Get a full overview of all of the new Puppet Enterprise capabilities here: https://puppetlabs.com/puppet/whats-new/ Or review the docs here: https://docs.puppetlabs.com/pe/3.1/ Want to see it in action? Attend a 30-minute, live technical webinar on Thursday, October 17, demonstrating the new Puppet Enterprise event inspector. Register today: https://cc.readytalk.com/cc/s/registrations/new?cid=wkzlqmd5myxr We hope you enjoy this release, and we look forward to your feedback! Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Sync data between various PuppetDB instances
On Tue, Oct 15, 2013 at 6:51 AM, Pablo Fernandez pablo.fernan...@cscs.chwrote:
Hehe, sorry for the auto-reply... but I made it work, and I wanted to
post it for reference.
The key was to add also the edges: it can't be an empty list.
For the record, doing:
# curl -vv -G -H Accept: application/json '
http://localhost:8080/v2/commands' --data-urlencode 'payload={
command: replace catalog,
version: 2,
payload: {
\metadata\: {
\api_version\: 1
},
\data\: {
\name\: \myhost.blabla.bla\,
\version\: \\,
\edges\: [
{\source\: {\type\: \Service\, \title\: \iptables\},
\target\: {\type\: \Service\, \title\: \iptables\},
\relationship\: \before\}
],
\resources\: [
{\type\: \Service\,
\title\: \iptables\,
\exported\: false,
\file\: \/etc/puppet/modules/puppetdb/manifests/server.pp\,
\line\: 121,
\tags\: [\node\, \puppetdb\],
\parameters\: {\hasrestart\: true, \ensure\ : \running\}
}
]
}
}
}'
Works like a charm, and add a new host into the PuppetDB out of the blue.
Next: automatically serialize those escaped quotes and try to see if it
exported resources work as they should.
Thanks, and sorry again for the noise,
BR/Pablo
Hi Pablo, I'm glad you got this working and I apologize it took so long. A
few comments:
1) You don't need to formulate the payload as a pre-serialized JSON
string (with all the requisite escaping and whatnot) anymore. As of
replace catalog version 2, you can just inline the raw JSON object itself:
payload: {data: ..., metadata: ..., ...}
The entire command is a single JSON object that way, and the payload is
just a normal value in that hash.
2) You are correct that the edges key is required, and should contain every
relationship specified in the supplied catalog:
http://docs.puppetlabs.com/puppetdb/1.5/api/wire_format/catalog_format.html#main-data-type-catalog
I do agree that the error message isn't helpful at all, though, and we
should fix that. It's likely that we aren't doing proper validation on that
and letting things get to the storage code, which throws an opaque,
low-level error that is difficult to debug. That said, as there aren't any
relationships specified in your above set of resource (no require/subscribe
params, for example) I'm curious why the empty list of edges fails. That
smells like a bug to me; would you mind filing a ticket against PuppetDB
with the above command included? We can take a look and see what's up.
3) With curl, you can supply an argument of --data-urlencode
payl...@mycatalog.json. Then you can just put the payload in a
mycatalog.json file, and curl should automatically load the content and
urlencode it for you. See
http://curl.haxx.se/docs/manpage.html#--data-urlencode
deepak
On 10/15/2013 11:25 AM, Pablo Fernandez wrote:
If I try to add a fictitious resource:
{\type\: \Service\,
\title\: \iptables\,
\exported\: false,
\file\: \/etc/puppet/modules/puppetdb/manifests/server.pp\,
\line\: 121,
\tags\: [\node\, \puppetdb\],
\parameters\: {
\ensure\ : \running\}
}
I get:
2013-10-15 11:20:43,042 ERROR [command-proc-45] [puppetdb.command]
[15abcd55-b7c6-4acc-8839-94b96f85ba68] [replace catalog] Retrying after
attempt 8, due to: org.postgresql.util.PSQLException: No value specified
for parameter 1.
This way of issuing commands is quite nasty...
BR/Pablo
On 10/15/2013 11:00 AM, Pablo Fernandez wrote:
Ok, so I finally opted for inserting a full node from one DB into another,
since getting the resources should be quite easy with a GET.
But then I run into a problem when running the replace catalog command
(with an empty catalog):
curl -vv -G -H Accept: application/json '
http://localhost:8080/v2/commands' --data-urlencode
'payload={command:replace catalog,version: 2,payload:{
\metadata\: {\api_version\: 1}, \data\: {\name\: \
puppet09.cscs.ch\,\version\: \\, \edges\: [], \resources\:
[] }}}'
Which returns ok. The puppetdb.log shows:
2013-10-15 10:42:02,060 ERROR [command-proc-45] [puppetdb.command]
[43c41752-e7d4-4725-b062-7b3a9b1ac8ec] [replace catalog] Retrying after
attempt 8, due to: org.postgresql.util.PSQLException: ERROR: syntax error
at or near )
Position: 66
I have looked again and again into the data, and syntax seems to be
correct.
Anybody tried this? Hints?
Thanks a lot,
Pablo Fernandez
On 10/10/2013 05:23 PM, Throwe, Jesse wrote:
That would really depend on the approach ultimately taken for the
multi-master. If the puppet master (or agent in masterless mode) forwards
the same fact/report/node/etc data to multiple puppetdb instances then yes
the scale breaks horribly and does not meet part of this request. If there
is some kind of store-and-forward mechanism in puppetdb itself, it would be
possible to extend the forward to
[Puppet Users] hiera_array, structured data and multiple levels of hierarchy
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple files
with separate data for each file, all dependent on the hiera hierarchy.
Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending on
the structure above. I want each sudoers definition to be in it's own file
in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not using
'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs, hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: [mcollective] mc does not discover any nodes
To get the agent, you need to install mcollective-service-agent as well, not just mcollective-service-common. Don't forget to restart the mcollective daemon after installing. On Thursday, October 10, 2013 2:34:07 AM UTC-7, Vincent Nawrocki wrote: Hi all ! I'm working on mcollective for a few days and I have a problem using agents. I'm on CentOS 6.4, using activeMQ 5.8.0 and mcollective 2.2.4. I Installed the service agent using yum on the client : yum install mcollective-service-common I can see it in the doc list using mco plugin doc. But now I want to use it and nodes never respond : -- [root@poste306 puppet]# mco ping poste306.s11.pfd time=161.65 ms poste302.s11.pfd time=163.25 ms poste304.s11.pfd time=166.48 ms ping statistics 3 replies max: 166.48 min: 161.65 avg: 163.79 [root@poste306 puppet]# mco rpc service status service=httpd Discovering hosts using the mc method for 2 second(s) 0 No request sent, we did not discover any nodes. --- I don't see what's wrong. No input in the mcollective.log file. Nothing on both servers and client sides. I appreciate any help or hint about this issue. Regards, Vincent. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: pypuppetdb 0.0.4 / puppetboard 0.0.2
Just upgraded, looks awesome! On Tuesday, October 15, 2013 12:07:19 AM UTC-7, Daniele Sluijters wrote: Hello everyone, It's been way to long since the release but I finally had some time to sort a few things out and release updates to both pypuppetdb and Puppetboard. For those of you who have no idea what this is about: * pypuppetdb is a library to work with the PuppetDB API in Python; * Puppetboard is meant as a replacement to Puppet Dashboard leveraging PuppetDB through pypuppetdb as its datasource. New is PuppetDB 1.5 (API v3) compatibility. None of the new features of API v3 have been implemented yet, that's going to be the goal for the coming weeks but everything that used to be possible with API v2 + Experimental is now available over API v3. Because PuppetDB 1.5 dropped the /experimental endpoints those have been removed from pypuppetdb too, even for older versions of PuppetDB. Puppetboard has gained a metrics tab and facts now have pretty pie-charts as well as an assorted set of small fixes and improvement across the board. Once pypuppetdb has gained support for all the new features in API v3 there are going to be some significant changes to Puppetboard, both in its capabilities and the UI. For those of you who will be at Puppet Camp London in November, I'm hoping I'll be able to show you at least some of that. As usual you can get the code from: * pypuppetdb: https://github.com/nedap/pypuppetdb or `pip install pypuppetdb` * puppetboard: https://github.com/nedap/puppetboard -- Daniele Sluijters -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Sync data between various PuppetDB instances
On Thu, Oct 10, 2013 at 6:12 AM, Pablo Fernandez pablo.fernan...@cscs.chwrote: Thanks Ken, I took a look at the Command API and seems to be quite interesting, but it triggers a few more questions. As a reminder (also for others), what I wanted to do was to add exported resources from Node_A (managed by PuppetMaster_A that has its own PuppetDB_A) into a different PuppetDB_B, where Node_A is unknown, in order for other Nodes_B (managed by PuppetMaster_B) be aware and possibly realize those exported resources. Taking a look the Commands API seem to capabilities to change a whole catalog, or facts. Do they need to be existing catalogs, or could I add new ones? I am thinking: If I want to add Node_A's exported resource(s) to PuppetDB_B, I could artificially add its whole catalog to PuppetDB_B... but the Command API is replace catalog, no add catalog. Would it be rejected? How does the first catalog of a node get introduced into the DB? And moreover, how do I query a whole catalog? Lots of great questions here! :) * You can certainly add the whole catalog for a node to a secondary PuppetDB * The command is called replace catalog to indicate that it's, well, a replacement operation. So if you already have a catalog for node foo.comstored, issuing a replace catalog with a new catalog for foo.com will cause PuppetDB to delete the old catalog and store the new one for foo.com. It does this atomically, of course. This is normal operation for PuppetDB, as it only stores a single catalog for a given node. * A replace catalog command won't be rejected if there's already a catalog for that node; it'll just tell PuppetDB to store new data in place of the old data. In fact, this is how PuppetDB works with puppetmasters today...an agent requests a catalog from the master, the master compiles it for the agent, and the master issues a replace catalog command to puppetdb accordingly. * There is an endpoint to get the catalog for a node: /v3/catalogs/foo.com. The wire format of the result should be the same, documented catalog wire format as during insertion: http://docs.puppetlabs.com/puppetdb/1.5/api/wire_format/catalog_format.html. I do believe, though, that we overlooked adding documentation for this new endpoint...apologies! A pull req adding those docs to the documentation/ directory of puppetdb would be much appreciated. :) Another possibility would be to include the resource inside an existing Node_B catalog on the PuppetDB_B (after all, exported resources don't really mater what node do they belong, as long as they have the right attributes, right?), but the Catalog wire format seems to require the whole set of resources, so, if I define the resources of Node_B with some exported resources from Node_A, I believe I would lose the original Node_B's resources. The only possibility would be to query Node_B full catalog, and *add also* those resources from Node_A before sending them to the DB... and this seems to me like a bit dirty :) Yes, you'd have to get the catalog for a node, modify it, and resubmit it. Remember that command submission is asynchronous, commands can be retried, etc. If you have a command of the form add some resources to the currently stored catalog, the definition of currently stored isn't a static thing. It's thus subject to race conditions and other confusion. By requiring an entire catalog be submitted, and by making it clear through the name of the command itself (replace catalog) a large class of problems go away while still keeping throughput high and retry-handling manageable. I'm not opposed to the idea of a merge type of command for catalogs, of course...but I think it's something that should be approached cautiously, with a good understanding of how it will impact (and be impacted by) the rest of the system. Maybe doing something like a command that merged a set of resources into a known, specific catalog (identified by a stable hash or id) would work? Am I missing anything? Or is there another way to implemen what I need with Puppet 3.2? Thanks again, BR/Pablo On 10/10/2013 09:16 AM, Ken Barber wrote: Is there a mechanism to pull and push some exported resources from one PuppetDB to another? I guess this could be done with the API, but has anybody tried it, or will it work at all? Not provided by us, yet. We've had a lot of discussions internally about this kind of thing. How about you outline your requirements in the form of a feature request here: http://projects.puppetlabs.com/projects/puppetdb/issues Did anybody try to push data to a PuppetDB by hand? The API does not seem to have the PUT or POST methods. The client obviously pushes uses POST :-). The documentation for the mechanism is here: http://docs.puppetlabs.com/puppetdb/1.5/api/commands.html ken. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop
Re: [Puppet Users] Using file and mount more efficiently
Thanks for the reference, John. We need to ensure that these remote mounts are owned/grouped by specific UID/GID -- hence why I had ownership involved there. We could do this via UID/GID only (not name) if that works better? I don't understand how apply that ownership to /home/201301 would affect / or /home. Then, Puppet would need to check that it's present, has the correct permissions and owership, and ensure it's mounted -- or, in the case of aged data, not mounted and not present. Thanks. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Building another Puppet module for Splunk
Hi All, I've been working on yet another Puppet module to deploy and manage Splunk. Yep, I know that there are already many out there, but none do what I need and also work the way we work and also have control of the various conf files built in. It's still a work in progress and isn't fully documented, but it is working for systems running RHEL 6. I also plan to get it working and featurefull for Windows systems as well. I'm sure that Debian support wouldn't be too hard either, but I'll leave that to others to do if they so choose. This is also my first github project, coincidentally. You can find it here: https://github.com/ITBlogger/puppet-module-splunkmgr I've tried to follow Puppet's style guide as much as possible and have used Puppet Labs' own NTP module as a style reference as well. Sorry that the manifests related to managing the conf files (particularly the Splunk App for *nix one) aren't all that easy to read, but the module is managing a lot of stanzas in the conf files. A few things you should know to use the module: It requires - This https://github.com/ITBlogger/puppet-splunk_conf/tree/patch-1 branch of cwooley's splunk_conf module which uses augeas to manage the conf file stanzas. I'm waiting for him to merge in my pull request, but until then you'll need to use my branch. This is because I changed his module to decouple stanza names from resource titles. This allows you to modify stanzas in two different conf files if needed. I originally did this so that Splunk and Splunk Universal Forwarder could be on the same system, but found this to be unnecessary in Splunk 6, but still liked the ability to name resource titles differently from stanza names. - The puppetlabs/firewall module - Puppet 3.0 or higher - All packages be served up by a private repo server - this could easily be changed to suit your needs, but this is how we work. We avoid putting installers and packages within Puppet modules and leverage Puppet's package management and software installation providers It is written to take advantage of hiera, but use of hiera isn't strictly necessary, although the documentation is written with hiera in mind using yaml as the backend. After using hiera for a few months, I can't imagine a better way to manage nodes. As we are PE customers, we never used node classifier manifests and instead used the dashboard to manage nodes and hiera is way better than that. I also like it better than node classifier manifests as those put configuration data into your Puppet modules and I'm definitely a believer in keeping data and config management modules separate. Any input or constructive criticism you have would be much appreciated. Regards, Alex -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending on
the structure above. I want each sudoers definition to be in it's own file
in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not using
'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs, hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: What's your hiera tree look like?
I couldn't get hiera integrated with PE 3.0.1 to work with nested
hierarchies, so this is what my hierarchy looks like:
:hierarchy:
- defaults
- %{clientcert}
- %{domain}
- %{osfamily}
- %{environment}
- global
Regards,
Alex
On Tuesday, March 19, 2013 2:30:16 PM UTC-7, Larry Fast wrote:
My Hiera tree is turning into a chaotic mess. I'm guessing that my tree
structure is one problem source. So I'm wondering how other real users have
setup hiera. Here are the core problems that are giving me headaches.
# I need to version control my modules separately but hiera data is
monolithic. If I need to change anything anywhere, I need to release a new
version of the whole tree.
# I can't easily review the final output from hiera within puppet because
the traversal is dependent on facts. I need to feed the facts into Hiera
before I get anything meaningful.
# Can't easily compare the config of two different servers. (really the
same as the previous)
Here's my Hiera tree. I'm very interested to know how others deal with
these issues. Does Puppet Enterprise include Hiera mgmt tools?
- %{environment}/%{project}/%{server_env}/%{module_name}
- %{environment}/%{project}/%{server_env}/common
- %{environment}/%{project}/%{role_name}-role/%{module_name}
- %{environment}/%{project}/%{role_name}-role/common
- %{environment}/%{project}/%{module_name}
- %{environment}/%{location}/%{module_name}
- %{environment}/%{module_name}
- %{environment}/common
NOTES:
Each Environment is a copy of our git repo and includes the hiera tree.
Project, Server_env, Role_name Location are custom facts
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested directory
works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not using
'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs, hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Yeah, I'll have to try again after upgrading to PE 3.1 which was just
released.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested directory
works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Status of Data in modules
On Tuesday, October 15, 2013 8:08:10 AM UTC-5, jcbollinger wrote: I'm not saying that categorically getting rid of ::params classes is a viable target. In fact, I don't really understand why it was ever an objective in the first place. On the other hand, I don't see why it makes sense for Puppet to give special significance to that pattern, either. A more general data-in-modules feature such as I describe would give users the option to avoid ::params classes in some cases, and I'm inclined to think that it would be easier to implement, to understand, and to use. John I agree with this. It seems the proposed new solution adds complexity and non-intuitive value lookups that could confuse users. I think the data-in-modules feature sounds useful. Perhaps as John suggests a change in scope is needed. Instead of getting rid of params.pp the scope should be to move hierarchical data out of params.pp and leave variables derived from logic in params.pp. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Dumb question...have you tried loading the data into a hiera array since
that's apparently what it's looking for?
Another dumb question...what's the pipe (|) for in your yaml data?
Unfortunately, the hiera documentation on the Puppet site is a bit thin and
I don't see that in the examples.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested directory
works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at least
let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that, so
there may be some differences with that and the version of hiera that you
are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully with
some code examples :) I've been banging my head on this for the better
part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Status of Data in modules
On Friday, October 11, 2013 7:12:32 PM UTC-5, Chuck wrote: What would be nice but not necessary: 1) defined variable automatically have classname added to avoid global conflicts. eg. Module: apache variable: port becomes global hiera: apache::port +1 Defining a variable in a module but having it's scope be global seems counter intuitive and could lead to conflicts. If someone wants a topscope variable they should probably define it in a topscope location (ENC, Centralized Hiera Files, etc) -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Yes to the array. I get this error when I try:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
As for the pipe, it preserves newlines:
http://en.wikipedia.org/wiki/YAML#Newlines_preserved
On Tuesday, October 15, 2013 7:38:50 PM UTC-7, Alex Scoble wrote:
Dumb question...have you tried loading the data into a hiera array since
that's apparently what it's looking for?
Another dumb question...what's the pipe (|) for in your yaml data?
Unfortunately, the hiera documentation on the Puppet site is a bit thin and
I don't see that in the examples.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested
directory works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at
least let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that,
so there may be some differences with that and the version of hiera that
you are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::clientcert}
- datacenter/app/role/%{::server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/ depending
on the structure above. I want each sudoers definition to be in it's own
file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::sudo_configs,
flatten(hiera_debug_array('sudoers')))
}
define sudo_crap::sudo_configs($filename, $contents) {
file {/tmp/etc/sudoers.d/$filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully
with some code examples :) I've been banging my head on this for the
better part of 2 weeks :)
Thanks!
David
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: hiera_array, structured data and multiple levels of hierarchy
Great thanks...still learning.
On Tue, Oct 15, 2013 at 7:53 PM, David Patterson
pattersondav...@gmail.comwrote:
Yes to the array. I get this error when I try:
# Error: Could not run: Hiera type mismatch: expected Array and got Hash
As for the pipe, it preserves newlines:
http://en.wikipedia.org/wiki/YAML#Newlines_preserved
On Tuesday, October 15, 2013 7:38:50 PM UTC-7, Alex Scoble wrote:
Dumb question...have you tried loading the data into a hiera array since
that's apparently what it's looking for?
Another dumb question...what's the pipe (|) for in your yaml data?
Unfortunately, the hiera documentation on the Puppet site is a bit thin and
I don't see that in the examples.
Thanks,
Alex
On Tuesday, October 15, 2013 3:43:00 PM UTC-7, David Patterson wrote:
Thanks for the reply, Alex! I'm using puppet-3.3 and the nested
directory works fine...at least for more simple modules, heh!
David
On Tuesday, October 15, 2013 2:47:34 PM UTC-7, Alex Scoble wrote:
I personally couldn't get hiera to work with nested directories in the
hiera.yaml.
In my case the hierarchy would look like:
:hierarchy:
- defaults
- %{::clientcert}
- %{::server_role}
- %{::app_name}
- %{::datacenter}
- global
You might try it flattened like that and see if that works. Will at
least let you know if nesting is the problem.
FYI, I'm using PE 3.0.1 and the version of hiera that comes with that,
so there may be some differences with that and the version of hiera that
you are using.
Hope that helps at least a little.
Regards,
Alex
On Tuesday, October 15, 2013 9:47:19 AM UTC-7, David Patterson wrote:
Hi all!
I'm trying to setup a puppet module for sudo that will write multiple
files with separate data for each file, all dependent on the hiera
hierarchy. Here's the relevant portion of my hiera.yaml:
:hierarchy:
- datacenter/app/role/node/%{::**clientcert}
- datacenter/app/role/%{::**server_role}
- datacenter/app/%{::app_name}
- datacenter/%{::datacenter}
- common
Basically, a node can have different files in /etc/sudoers.d/
depending on the structure above. I want each sudoers definition to be in
it's own file in /etc/sudoers.d/.
Here's how I have my data files laid out (yaml):
common.yaml:
sudoers:
- filename: app1_sudo
- contents: |
%wheel ALL=(ALL) ALL
- filename: app2_sudo
- contents: |
%app2 ALL=(ALL) ALL
%app3 ALL=(ALL) ALL
datacenter/datacenter.yaml:
sudoers:
- filename: datacenter1_sudo
- contents: |
%datacenter1 ALL=(ALL) ALL
- filename: datacenter2_sudo
- contents: |
%datacenter2 ALL=(ALL) ALL
%datacenter3 ALL=(ALL) ALL
This is the closest I've been able to get, however, notice I'm not
using 'hiera_array', thus, only 1 level of hierarchy is written.
class sudo_crap {
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::**sudo_configs,
hiera_debug_array('sudoers'))
# works for only one level of hierarchy
create_resources(sudo_crap::**sudo_configs, hiera_debug('sudoers'))
# Errors with:
# Error: Could not run: Hiera type mismatch: expected Array and got
Hash
#create_resources(sudo_crap::**sudo_configs,
flatten(hiera_debug_array('**sudoers')))
}
define sudo_crap::sudo_configs($**filename, $contents) {
file {/tmp/etc/sudoers.d/$**filename:
owner = root,
group = root,
mode = 644,
content = $contents,
}
}
include sudo_crap
Any ideas what I'm doing wrong and how I can solve this? Hopefully
with some code examples :) I've been banging my head on this for the
better part of 2 weeks :)
Thanks!
David
--
You received this message because you are subscribed to a topic in the
Google Groups Puppet Users group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/puppet-users/ZQjzAife5-k/unsubscribe.
To unsubscribe from this group and all its topics, 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.
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] puppetdb, foreman, one particular node has a problem
I have about 75 nodes now and recently added 6 of them. They are all running Debian squeeze and all have exactly the same Puppet packages. One is giving an error when I try to enroll it: Failed to import facts: PG::UndefinedColumn: ERROR: column environment of relation hosts does not exist LINE 1: ...d, created_at, disk, domain_id, enabled, environme... : INSERT INTO hosts (architecture_id, build, certname, comment, compute_resource_id, created_at, disk, domain_id, enabled, environment, environment_id, hostgroup_id, image_file, image_id, installed_at, ip, last_compile, last_freshcheck, last_report, location_id, mac, managed, medium_id, model_id, name, operatingsystem_id, organization_id, owner_id, owner_type, ptable_id, puppet_ca_proxy_id, puppet_proxy_id,puppet_status, root_pass, serial, source_file_id, subnet_id, type, updated_at, use_image, uuid) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27, $28, $29, $30, $31, $32, $33, $34, $35, $36, $37, $38, $39, $40, $41) RETURNING id Rendered text template (0.0ms) theres nothing special about this node and other enrollments I've done today have been fine. Exactly the same environments, same packages, same everything. Whats different? -- 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. For more options, visit https://groups.google.com/groups/opt_out.
