[Puppet Users] Re: Best Practices on node declaration
Thank you very much guys.
Hiera saved my life ;-)
Le mercredi 21 novembre 2012 18:46:06 UTC+1, AnOnJoe a écrit :
>
> Hello,
>
> I would like to know what are the best pratices in node declaration.
>
> I tried to play with inheritance with failures :
> Here my* puppet/manifest/site.pp*
>
> node basenode {
>> class { 'ssh': }
>> class { 'ntp': }
>> class { 'users': }
>> class { 'sudo': }
>> }
>>
>> node default inherits basenode {
>> }
>>
>>
>> # serv1
>>
>> node "serv1" inherits basenode {
>> class { 'sudo' :
>> sudoers => "sudoers_serv1"
>> }
>> class { 'debug': }
>> }
>>
>
> As you can see i have to manage 2 sudoers file :
> One in almost all server, and an other one in my "serv1" server
>
> here is my *sudo class*
>
> class sudo ($sudoers="sudoers") {
>> package { 'sudo':
>> ensure => installed,
>> }
>> file { '/etc/sudoers':
>> source => "puppet://puppetmaster.foo.com/sudo/$sudoers",
>> ensure => file,
>> mode => 440,
>> owner => 'root',
>> group => 'root',
>> require => Package['sudo'],
>> }
>> }
>>
>
>
> Can you tell me what is the best way to resolve that kind of problems.
>
> Thx
>
--
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/-/Q416Qk8wJgYJ.
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] Re: Fileserver in standalone mode.
> > My workaround for now is to simply move the files to a module named files > and reference them as "puppet:///modules/files/path/to/file", but it seems > like there might be a better solution. I don't know about better, but you can also use file:///... URIs in the source parameter. Cheers, Paul -- 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/-/C1qDjVbxRiwJ. 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] Report processor and available variables
Hello, I'm trying to build a custom report processor so that I can get puppet metrics into Zabbix. I found one here: https://github.com/thomasvandoren/puppet-zabbix which basically works. The problem I have is that report processor mostly use self.host as hostname. But it represent certname in "puppet world". I tried @hostname, but still get certname instead of hostname. Is there any way to get the real hostname into report processor ? Regards, Jean-Baptiste Favre -- 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] Fileserver in standalone mode.
On Thu, 2012-05-24 at 09:37 -0700, btimby wrote: > I am using puppet in standalone mode (puppet apply) to test manifests > that I also use in a client/server configuration. > > I have everything working as far as files included in modules. I can > reference file source as "puppet:///modules/modulename/path/to/file". > > However, some files are not part of a module, so for the client/server > portion, I just set up a share called files. However, references to > these files "puppet://files/path/to/files" don't work in standalone > mode. Because it tries to resolve a host called 'files' as the server where to get those files. Have you tried: puppet:///files/path/to/files (notice the ///) > I understand that standalone mode (puppet apply) command can find the > module files because you tell it the path to look in (--modulepath > argument). Why is there no argument for adding file shares > (--fileserver=files:/path/to/files)? Is there another way to achieve > this? > > My workaround for now is to simply move the files to a module named > files and reference them as "puppet:///modules/files/path/to/file", > but it seems like there might be a better solution. You could also setup a puppetmaster only for the purpose of serving files to your servers, and use: puppet://fileserver.domain.com/files/path/to/file kind of url. It's still masterless for compilation purposes, but uses a master for file serving. -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- 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] Re: Best practices on puppet installation
Thanks Pete, Ugo On Thursday, November 22, 2012 8:20:31 AM UTC-5, Ugo Bellavance wrote: > > Hi, > > We have ~20 Red Hat servers and usually use EPEL as third-party repo. I'm > currently using the packages provided by this repo (2.6.17-2), but I was > wondering what were the pros and cons of using puppetlabs' repo instead. I > can see that it provides puppet 3.x, facter 1.6.14 and hiera (which is > unavailable in EPEL but I haven't started using it). > > I currently have a very basic setup but want to use puppet more in the > future. I also installed foreman on the same machine, which is not really > usefull for me because the only thing that works on it is the display of my > host and facts (I use kickstart scripts for provisionning). I haven't been > able to make the rest work (partly because I don't use modules yet). I can > see that puppetlabs' repo provides puppet-dashboard which may do the same > thing and maybe more. > > I can see that there are pros to use this repo but if I do, will I have to > enable it on all my puppet agents or will my EPEL-provided agents be able > to talk with the 3.0 puppet-server without restriction? > > Thanks, > > Ugo > -- 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/-/SFpXi9a9G6QJ. 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] Best practices on puppet installation
But will I need to put all my agents to 3.0 as well? Ugo On Thursday, November 22, 2012 6:16:26 PM UTC-5, Pete wrote: > > On 22 November 2012 23:20, Ugo Bellavance >wrote: > >> Hi, >> >> We have ~20 Red Hat servers and usually use EPEL as third-party repo. >> I'm currently using the packages provided by this repo (2.6.17-2), but I >> was wondering what were the pros and cons of using puppetlabs' repo >> instead. I can see that it provides puppet 3.x, facter 1.6.14 and hiera >> (which is unavailable in EPEL but I haven't started using it). >> >> I currently have a very basic setup but want to use puppet more in the >> future. I also installed foreman on the same machine, which is not really >> usefull for me because the only thing that works on it is the display of my >> host and facts (I use kickstart scripts for provisionning). I haven't been >> able to make the rest work (partly because I don't use modules yet). I can >> see that puppetlabs' repo provides puppet-dashboard which may do the same >> thing and maybe more. >> >> I can see that there are pros to use this repo but if I do, will I have >> to enable it on all my puppet agents or will my EPEL-provided agents be >> able to talk with the 3.0 puppet-server without restriction? >> > > > Hi Ugo, > > You will get the current versions on the puppetlabs repo but you will also > get versions that may disrupt your setup. > My advice would be to switch to 3.0 before you get to far in. > It adds a bunch of extra functionality and speedups and and switching your > setup to 3.0 later will be a pain. > > If you don't have a testing environment setup I would also recommend you > set one up running 3.0 and test your modules with that before switching > your production environment over. > > Some reference material to help you switch > http://docs.puppetlabs.com/guides/upgrading.html > > > > http://docs.puppetlabs.com/puppet/3/reference/release_notes.html#backwards-incompatible-changes-in-30 > This section primarily but the whole page will help as well. > > Good luck! > (I am in the process of switching my testing environment over to 3.0.1 so > if you get suck I may be able to help) > > Pete. > > >> Thanks, >> >> Ugo >> >> -- >> 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/-/KOjUMvvEDowJ. >> To post to this group, send email to puppet...@googlegroups.com >> . >> To unsubscribe from this group, send email to >> puppet-users...@googlegroups.com . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- 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/-/zix1OOFyKnoJ. 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] passing array param to hiera
Hi,
I'm having an issue trying to pass an array parameter for a hiera lookup
hiera.yaml:
:hierarchy:
- some_place/%{hostnames}
dummy_host.yaml:
---
host: 'dummy_host'
instances:
dummy01:1.2.3.4
dummy02:1.2.3.4
dummy03:1.2.3.4
in my manifest I have:
$hostnames = [ 'dummy_host', 'dummy_host1' ]
$hiera_lookup = hiera('instances')
The above results in me getting the following error:
can't convert Array into String at manifest.pp:18 on node hostname
I also tried using hiera_array and hiera_hash without success.
Thank you for your help
Mike
--
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/-/9bffZQjQ190J.
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] Re: passing array param to hiera
FYI,
if I replace $hostnames = [ 'dummy_host', 'dummy_host1' ] by $hostnames =
'dummy_host'
this works.
On Friday, November 23, 2012 12:19:11 PM UTC-5, mickael avedissian wrote:
>
> Hi,
>
> I'm having an issue trying to pass an array parameter for a hiera lookup
>
> hiera.yaml:
> :hierarchy:
> - some_place/%{hostnames}
>
> dummy_host.yaml:
> ---
> host: 'dummy_host'
> instances:
> dummy01:1.2.3.4
> dummy02:1.2.3.4
> dummy03:1.2.3.4
>
>
> in my manifest I have:
> $hostnames = [ 'dummy_host', 'dummy_host1' ]
> $hiera_lookup = hiera('instances')
>
>
> The above results in me getting the following error:
> can't convert Array into String at manifest.pp:18 on node hostname
>
>
> I also tried using hiera_array and hiera_hash without success.
>
> Thank you for your help
> Mike
>
--
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/-/jkGKvIGafmkJ.
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] how to query yaml file with hiera function.
Hi guys,
i have a hiera.yaml config file like this:
---
:hierarchy:
- %{env}/%{tmp_module_name}
- %{env}/%{tmp_module_name}.common
:backends:
- yaml
:yaml:
:datadir: '/etc/puppet/hieradata'
I also have a test/some_module.yaml file like this:
---
db:
root: pass
port: '3306'
I am also using the hiera function from a template like this
class.pp
$::class::var='db'
template.erb
<%= scope.function_hiera([var]) %>
and that returns as expected the 'db' hash...
however , I would like to query the yaml file directly from the hiera
function with something like:
scope.function_hiera([var:root]), so to have access directly to the
root:pass pair. but that doesnt seem to work.
I've tried several possibilities, eg: ([var:'root']), ([$var::'root']),
([$::class::var:root]), ([var:['root']]) without success,
Now i know that something like <%= scope.function_hiera([var])['root']
would work!
The problem with this approach is that the next level in the hierarchy
would never be reached since the 'db' key will always be located in the
first level... but what if I would like to use something like this:
First search level:
---
db:
root: pass
port: '3999'
Second search level
---
db:
root: pass
port: '3999'
path : 'foo'
then the path:foo pair would never be located...
Btw, are there any plans to fix this soon:
http://projects.puppetlabs.com/issues/14985
thanks in advance,
evelio
Using ubuntu 12.04 LTS
Package: puppet
Version: 3.0.1-1puppetlabs1
--
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/-/wWVVXkBB-ywJ.
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] exec 'refresh' attribute possible values
A quote from http://docs.puppetlabs.com/references/latest/type.html#exec refreshHow to refresh this command. By default, the exec is just called > again when it receives an event from another resource, but this parameter > allows you to define a different command for refreshing. A different command... like what? What does it add to 'refreshonly' attribute? Actually, what I'm looking for, is a conditional triggering of one exec by another. That is exec1 notifies exec2 only if exec1 command has been actually executed. 'onlyif' can prevent the execution of exec1 itself, but doesn't prevent, say, notify=>Exec['2'] from happening. Thanks. -- 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/-/zlP8oOScoFIJ. 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] Best practices on puppet installation
On Fri, Nov 23, 2012 at 3:46 PM, Ugo Bellavance wrote: > But will I need to put all my agents to 3.0 as well? You'll be better off if you switch now, since the 2.x releases are in bugfix-only state. > On Thursday, November 22, 2012 6:16:26 PM UTC-5, Pete wrote: >>> able to make the rest work (partly because I don't use modules yet). I can >>> see that puppetlabs' repo provides puppet-dashboard which may do the same >>> thing and maybe more. puppet open source dashboard is not being actively developed, so you are better off with the foreman or the enterprise version of puppet. >>> I can see that there are pros to use this repo but if I do, will I have >>> to enable it on all my puppet agents or will my EPEL-provided agents be able >>> to talk with the 3.0 puppet-server without restriction? You'll be better off getting the puppet agent from the PuppetLabs yum repo's. They are kept up to date by people who know what they are doing, so the chance of trouble is much smaller. good luck, -- Walter Heck -- Check out my startup: Puppet training and consulting @ http://www.olindata.com Follow @olindata on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/olindata -- 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] Best practices on puppet installation
Hello, 2012/11/23 Walter Heck > On Fri, Nov 23, 2012 at 3:46 PM, Ugo Bellavance wrote: > > But will I need to put all my agents to 3.0 as well? > You'll be better off if you switch now, since the 2.x releases are in > bugfix-only state. > You don't need to upgrade your agents. They would work fine with puppetmaster 3.0. But as Walter already mentioned, it would be definitively better also to switch them to 3.0 version. The more you don't have any fancy setup yet and it should be easy in comparison to benefits it can give you. > > On Thursday, November 22, 2012 6:16:26 PM UTC-5, Pete wrote: > >>> able to make the rest work (partly because I don't use modules yet). > I can > >>> see that puppetlabs' repo provides puppet-dashboard which may do the > same > >>> thing and maybe more. > puppet open source dashboard is not being actively developed, so you > are better off with the foreman or the enterprise version of puppet. > > >>> I can see that there are pros to use this repo but if I do, will I have > >>> to enable it on all my puppet agents or will my EPEL-provided agents > be able > >>> to talk with the 3.0 puppet-server without restriction? > You'll be better off getting the puppet agent from the PuppetLabs yum > repo's. They are kept up to date by people who know what they are > doing, so the chance of trouble is much smaller. > 100% agreement. Best, -- Dominik Żyła -- 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] how to query yaml file with hiera function.
Hi,
2012/11/23 Evelio VILA
> Hi guys,
>
> i have a hiera.yaml config file like this:
>
> ---
> :hierarchy:
> - %{env}/%{tmp_module_name}
> - %{env}/%{tmp_module_name}.common
> :backends:
> - yaml
> :yaml:
> :datadir: '/etc/puppet/hieradata'
>
>
> I also have a test/some_module.yaml file like this:
>
> ---
> db:
> root: pass
> port: '3306'
>
>
> I am also using the hiera function from a template like this
>
> class.pp
> $::class::var='db'
>
> template.erb
> <%= scope.function_hiera([var]) %>
Try this: <%= scope.function_hiera([var['root']]) %>
--
Dominik Żyła
--
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] Re: Puppet & Oracle Database config management
On Thu, Nov 22, 2012 at 04:18:02AM -0800, Gavin Williams wrote:
> Ok, I've come back to this functionality, and need to move it along...
>
> My challenge now is how I can use the oratab resource to trigger other
> actions...
>
> So if oratab creates a new entry in /etc/oratab, then I want to ideally
> call a define which will go away and create the require directory
> structure, mount NFS volumes and add details to fstab...
>
> Any ideas???
>
> Cheers
> Gavin
Why do you need the resource to "trigger" anything? I guess you are
already using puppet to define your instances so you can do something
like
define oracle::instance($home, ...) {
# some instance specific subdirectory
file { "/u01/app/oracle/admin/${name}":
ensure => directory}
}
# some instance specific mount
mount { ...${name}:
ensure => mounted,
}
file { "responsefile_for_${name}":
ensure => file,
content => template("responsefile.cfg.erb",
}
exec { "install_db_${name}"
command =>
'some_wrapperscript_around_dbca_to_install_instance_with_responsefile',
creates => 'some_flagfile_the_wrapperscript_creates_on_success',
require => File["responsefile_for_${name}"],
}
oratab { $name:
ensure => present,
home => $home,
atboot => yes,
}
}
-Stefan
--
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] Re: Scope problem in 2.7.12, bug?
Bug reported here: http://projects.puppetlabs.com/issues/17799
On Mon, Nov 19, 2012 at 5:14 PM, jcbollinger wrote:
>
>
> On Sunday, November 18, 2012 2:35:56 PM UTC-6, Walter Heck - OlinData.com
> wrote:
>>
>> Hello,
>>
>> On Sun, Nov 18, 2012 at 6:47 PM, Stefan Heijmans
>> wrote:
>> > No, i's not, it is correct, see
>> > http://docs.puppetlabs.com/guides/scope_and_puppet.html
>> >
>> > At the moment you 'include mysql' only the top scope package variable is
>> > known, so there fore mysql package will be installed.
>> > swap them around and mysql-server package will get installed.
>> but I am specifically referring to _not_ the top-scope variable by
>> using $mysql_server::package. This is a scope that doesn't have that
>> variable (yet, anyway). I don't expect Puppet to just jump to a higher
>> level scope (top-scope in this case) to go and look for my variable
>> there.
>>
>
>
> I agree, it looks like a bug to me. A variable reference should never
> evaluate a variable that doesn't match the given name. I would file a
> ticket.
>
> The issue may be less straightforward than it first appears, however.
> Consider the difference between $mysql_server::package and
> $::mysql_server::package. In the vast majority of cases, I would expect
> them to evaluate to the same thing (including manifesting the same bug in
> this case). But what if there were also this class:
>
> class mysql::mysql_server {
> $package = 'mysql-server55'
> }
>
> Assume that mysql::mysql_server is declared before class mysql. What value
> do you then expect when class mysql dereferences $mysql_server::package?
> That is, do you get "mysql-server" from $::mysql_server::package or
> "mysql-server55" from $::mysql::mysql_server::package? I think you get the
> latter, and I think that's reasonable. Moreover, I would guess that the
> support for that behavior is where the bug is hiding.
>
>
> John
>
--
Walter Heck
CEO and Founder @ OlinData (http://olindata.com)
Puppet training and consulting
--
Follow @olindata on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/olindata
--
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] Puppet 3.0 Puppet labs repo package problem on rhel5
Hi, I'm having a weird issue and was wondering if anyone else had run into it. I recently upgraded from puppet 2.7 -> 3.0.1 After cleaning up some gems on my puppet master everything seemed to be working ok. I had originally used the EPEL repo's to deploy puppet, but switched to the Puppet Labs repos so I could upgrade to 2.7 then 3. On RHEL5 only, I get a RSTRING_PTR error if I upgrade to the Puppet Labs version (1.4.6) if I roll back to the EPEL veriosn of rubygem-json (1.4.3) Everything works again. Has anyone seen anything like this before? Thanks -a Rolling back to rubygem-json-1.4.3-3.el5.1 and everything works After Upgrade of rubygem-json Info: Retrieving plugin /usr/bin/ruby: symbol lookup error: /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/json/ext/parser.so: undefined symbol: RSTRING_PTR [root@rhel5build-10wa gems]# rpm -qi rubygem-json Name: rubygem-json Relocations: (not relocatable) Version : 1.4.6 Vendor: Puppet Labs Release : 1.el5 Build Date: Wed 26 Sep 2012 06:10:33 PM EDT Install Date: Fri 23 Nov 2012 05:11:36 PM EST Build Host: rpm-builder.puppetlabs.lan Group : Development/Languages Source RPM: rubygem-json-1.4.6-1.el5.src.rpm Size: 592354 License: Ruby or GPLv2 Signature : RSA/SHA1, Wed 26 Sep 2012 06:15:36 PM EDT, Key ID 1054b7a24bd6ec30 URL : http://json.rubyforge.org Summary : A JSON implementation in Ruby Description : This is a implementation of the JSON specification according to RFC 4627 in Ruby. You can think of it as a low fat alternative to XML, if you want to store data to disk or transmit it over a network rather than use a verbose markup language. Before Upgrade: [root@rhel5build-10wa ~]# rpm -qi rubygem-json Name: rubygem-json Relocations: (not relocatable) Version : 1.4.3 Vendor: Fedora Project Release : 3.el5.1 Build Date: Thu 16 Sep 2010 03:40:59 AM EDT Install Date: Mon 19 Nov 2012 03:54:16 PM EST Build Host: x86-03.phx2.fedoraproject.org Group : Development/Languages Source RPM: rubygem-json-1.4.3-3.el5.1.src.rpm Size: 629927 License: Ruby or GPLv2 Signature : DSA/SHA1, Mon 20 Sep 2010 12:40:46 PM EDT, Key ID 119cc036217521f6 Packager: Fedora Project URL : http://json.rubyforge.org Summary : A JSON implementation in Ruby Description : This is a implementation of the JSON specification according to RFC 4627 in Ruby. You can think of it as a low fat alternative to XML, if you want to store data to disk or transmit it over a network rather than use a verbose markup language. [root@rhel5build-10wa ~]# puppet agent --test Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/born_on.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Caching catalog for rhel5build-10wa Info: Applying configuration version '1353708172' Finished catalog run in 11.65 seconds -- 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] variable not replace when come from hiera
Hi,
I use puppet 2.7.16
i try to use hiera to store file data
yaml file :
apt:
'/etc/apt/preferences.d':
ensure: directory
recurse: true
source: "puppet:///$environment/$module_name/preferences.d"
When i try to use it with create_resource , it fail because $environment
and $module_name are not replace.
$instance_apt = hiera("apt")
$defauts = hiera("apt.defauts")
create_resources(file,$instance_apt,$defauts)
->
err: /Stage[main]/Apt/File[/etc/apt/preferences.d]: Failed to generate
additional resources using 'eval_generate: Error 400 on SERVER: Cannot find
file: Invalid path '$environment'
When i do the same with a hash, it work :
$defauts = hiera("apt.defauts")
$instance_apt = {
"/etc/apt/preferences.d" => {
ensure => directory,
recurse => true,
source => "puppet:///$environment/$module_name/preferences.d",
}
}
create_resources(file,$instance_apt,$defauts)
Is it a bug or a* *lack of functionality ?
Regards
Fred.
--
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/-/85vIsafxGuQJ.
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.
