[Puppet Users] best way to ensure (yum) package repository freshness ?
Hello, I have run into problems in the past where a package has been added to our yum repository, and a (new) class has been pushed to install that package, but puppet fails because the yum db on the target machine is too stale, and thus isn't aware of the existence of the new package. My question is this : what have other Puppet admins done in order to ensure that a target machine has the freshest local dbcache before attempting to install a package ? Thank you. -- Daniel Maher "The Internet is completely over." -- Prince -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Of classes, tags, and collections
Greetings all,
I'm running into an interesting problem that I'm hoping someone out
there knows more about than I.
Consider the following code:
class testa {
notify {
"note_testa": message => "Test A!";
"note2_testa": message => "Test A take 2!"
}
}
class testb {
notify { "note_testb": message => "Test B!" }
}
Notify<| tag == "testb" |> -> Notify<| tag == "testa" |>
node puptest {
include testa
include testb
}
-
In this case, what I'm trying to do is express the relationship that
any notification in the testb class (more generally, tagged with
'testb' – which any resource of the testb class should be, right?)
should occur before any notification in the testa class. In inspecting
the catalog and graph that results (relationships.dot), I would expect
to see the following relationships represented:
Notify[note_testb] -> Notify[note_testa]
Notify[note_testb] -> Notify[note2_testa]
However, I'm not seeing any relationships between the notifies at all
- the graph is disjoint, and the messages appear in any order.
"Hm," I thought to myself, "maybe this is because you can't look for
an individual tag like this in a collection, because the resource
doesn't just have one tag, it has a bunch of tags." But then I looked
at the 2.6.3 source code, and there appears to be a special case for
tag in collection expressions! If the LHS of the == condition says
tag, it looks like that will trigger a check to see if the resource is
tagged with the RHS value. So it looks to me like this usage of the
collection/relationship syntax was anticipated.
I note that if I change to Notify<| title == "note_testb" |> or just
to simple resource references like Notify[note_testb], the
relationship does take effect. But then, of course, it's just a 1-1
relationship, so I might as well just write requires.
I think this class-based and collection-based expression of
relationships could be extremely powerful and useful. Has anybody
managed to get anything like this working, or does anybody know a
reason why this shouldn't work?
Thanks!
-- O
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 way to ensure (yum) package repository freshness ?
On 18 Nov 2010, at 12:56 AM, Daniel Maher wrote:
> I have run into problems in the past where a package has been added to our
> yum repository, and a (new) class has been pushed to install that package,
> but puppet fails because the yum db on the target machine is too stale, and
> thus isn't aware of the existence of the new package.
>
> My question is this : what have other Puppet admins done in order to ensure
> that a target machine has the freshest local dbcache before attempting to
> install a package ?
We haven't run into this problem here, but I imagine something like the
following (untested) code might help:
exec { 'yum-clean-expire-cache':
user => 'root',
path => '/usr/bin',
command => 'yum clean expire-cache',
}
Package { require => Exec['yum-clean-expire-cache'] }
package { ['foo','bar']: ensure => present }
That should make Puppet revalidate all of yum's caches before attempting to
install either the foo or bar packages (or any packages for which the above
resource default is in scope). 'yum clean expire-cache' is the cheapest way to
ensure an updated view of your yum repos, without deleting too much metadata
which may need re-downloading in case the repos are unchanged. Note that this
clean would happen on every Puppet run, of course, and that may not be
desirable.
--
Ian Ward Comfort
Systems Team Lead, Academic Computing Services, Stanford University
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Of classes, tags, and collections
On 18 Nov 2010, at 1:06 AM, Owen Smith wrote:
> I'm running into an interesting problem that I'm hoping someone out
> there knows more about than I.
>
> Consider the following code:
>
>
> class testa {
> notify {
>"note_testa": message => "Test A!";
>"note2_testa": message => "Test A take 2!"
> }
> }
>
> class testb {
> notify { "note_testb": message => "Test B!" }
> }
>
> Notify<| tag == "testb" |> -> Notify<| tag == "testa" |>
>
> node puptest {
> include testa
> include testb
> }
> -
>
> In this case, what I'm trying to do is express the relationship that
> any notification in the testb class (more generally, tagged with
> 'testb' – which any resource of the testb class should be, right?)
> should occur before any notification in the testa class. In inspecting
> the catalog and graph that results (relationships.dot), I would expect
> to see the following relationships represented:
>
> Notify[note_testb] -> Notify[note_testa]
> Notify[note_testb] -> Notify[note2_testa]
>
> However, I'm not seeing any relationships between the notifies at all
> - the graph is disjoint, and the messages appear in any order.
>
> "Hm," I thought to myself, "maybe this is because you can't look for
> an individual tag like this in a collection, because the resource
> doesn't just have one tag, it has a bunch of tags." But then I looked
> at the 2.6.3 source code, and there appears to be a special case for
> tag in collection expressions! If the LHS of the == condition says
> tag, it looks like that will trigger a check to see if the resource is
> tagged with the RHS value. So it looks to me like this usage of the
> collection/relationship syntax was anticipated.
>
> I note that if I change to Notify<| title == "note_testb" |> or just
> to simple resource references like Notify[note_testb], the
> relationship does take effect. But then, of course, it's just a 1-1
> relationship, so I might as well just write requires.
>
> I think this class-based and collection-based expression of
> relationships could be extremely powerful and useful. Has anybody
> managed to get anything like this working, or does anybody know a
> reason why this shouldn't work?
You may be running across something as simple as a slight variation on bug
#4560:
https://projects.puppetlabs.com/issues/4560
In short, implicit tag assignment does not seem to be reliable.
--
Ian Ward Comfort
Systems Team Lead, Academic Computing Services, Stanford University
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 way to ensure (yum) package repository freshness ?
Perhaps you could adjust one of the /etc/yum.conf parameters like metadata_expire down from its default of 1.5 hours or keepcache = false (not entirely sure that this one does what you want it to do). The metadata_expire one can be set at the repo level so you could set it only for your own repo. On 18/11/2010 08:56, Daniel Maher wrote: > Hello, > > I have run into problems in the past where a package has been added to > our yum repository, and a (new) class has been pushed to install that > package, but puppet fails because the yum db on the target machine is > too stale, and thus isn't aware of the existence of the new package. > > My question is this : what have other Puppet admins done in order to > ensure that a target machine has the freshest local dbcache before > attempting to install a package ? > > Thank you. > -- Trevor Hemsley Infrastructure Engineer . *C A L Y P S O * Brighton, UK OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 . www.calypso.com This electronic-mail might contain confidential information intended only for the use by the entity named. If the reader of this message is not the intended recipient, the reader is hereby notified that any dissemination, distribution or copying is strictly prohibited. *P * /*/Please consider the environment before printing this e-mail /*/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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 way to ensure (yum) package repository freshness ?
On Nov 18, 2010, at 12:56 AM, Daniel Maher wrote: > Hello, > > I have run into problems in the past where a package has been added to our > yum repository, and a (new) class has been pushed to install that package, > but puppet fails because the yum db on the target machine is too stale, and > thus isn't aware of the existence of the new package. > > My question is this : what have other Puppet admins done in order to ensure > that a target machine has the freshest local dbcache before attempting to > install a package ? > > Thank you. What ever you do, you will probably want to make sure you have a caching proxy server (or an on site mirror) between your clients and the yum server. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: No changes being applied to clients 2.6.3rc3
It looks to me like the client is receiving an essentially empty catalog (all the resources I see mentioned belong to Puppet itself). Since that's apparently not what you expected, it probably implies an error in your manifests. Is there a node definition for this host? Does it specify any resources for the "fcprod" environment? Cheers, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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 way to ensure (yum) package repository freshness ?
On Nov 18, 2:56 am, Daniel Maher wrote: > My question is this : what have other Puppet admins done in order to > ensure that a target machine has the freshest local dbcache before > attempting to install a package ? I set up a cron job (via Puppet) that periodically performs a "yum clean all". That's a bit crude, and it allows for a delay before a new package is recognized and installed, but it works well enough for me. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: more errors with pushig out directories
On Nov 17, 8:50 pm, kiwi wrote:
> I am having grief with another directory -- almost identical set up as
> previous message. This time I am getting
>
> err: /Stage[main]/Monitor/File[/home/snort/conf/pp]: Failed to
> generate additional resources using 'eval_generate': Error 400 on
> SERVER: Not authorized to call search on /file_metadata/monior/pp/dmzo
> with {:recurselimit=>2, :recurse=>true, :links=>"follow"}
> err: /Stage[main]/Monitor/File[/home/snort/conf/pp]: Failed to
> retrieve current state of resource: Error 400 on SERVER: Not
> authorized to call find on /file_metadata/monior/pp/dmzo Could not
> retrieve file metadata for puppet:///monior/pp/dmzo: Error 400 on
> SERVER: Not authorized to call find on /file_metadata/monior/pp/dmzo
> at /etc/puppet/modules/monitor/manifests/init.pp:38
>
> From monitor/manifests/init.pp:
>
> "/home/snort/conf/pp":
> owner => 'snort',
> group => 'snort',
> source => "puppet:///monior/pp/$master",
> links => follow,
> recurse => true,
> recurselimit =>1,
> ensure => directory;
> as can be seen $master is being interpolated as 'dmzo' as it should
> be.
>
> from /etc/puppet:
>
> lrwxrwxrwx 1 root root 37 Nov 18 15:02 modules/monitor/files/pp/dmzo ->
> /home/sensors/Sensors/masters/dmzo/pp
>
> [rful...@secpupprd01 puppet]$ ls -l modules/monitor/files/pp/dmzo/
> total 92
> -rw-rw-r-- 1 sensors sensors 18379 Nov 18 14:52 disable.conf
> -rw-rw-r-- 1 sensors sensors 0 Nov 18 14:52 dropsid.conf
> -rw-rw-r-- 1 sensors sensors 65 Nov 18 14:52 enabled.conf
> -rw-rw-r-- 1 sensors sensors 2455 Nov 18 14:52 modified.conf
> -rw-rw-r-- 1 sensors sensors 2338 Nov 18 14:52 pp.conf
> -rw-r--r-- 1 sensors sensors 7886 Nov 18 14:52 pulledpork.conf
> -rw-rw-r-- 1 sensors sensors 8763 Nov 18 14:52 snort.conf
> -rw-rw-r-- 1 sensors sensors 7864 Nov 18 14:52 test.conf
>
> Any idea what is wrong here?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: more errors with pushig out directories
Oops, sorry for the empty post. On Nov 17, 8:50 pm, kiwi wrote: > Any idea what is wrong here? Could it simply be that you have misspelled 'monitor' in your resource's "source" property? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] No changes being applied to clients 2.6.3rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > So, the logs are reporting that everything was successful, yet nothing > is actually getting applied. Where can I begin to troubleshoot this > issue? what is the version of your master? ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlOPkACgkQbwltcAfKi38DRwCfZDMDufcLnpIIJyCNSO5tepyJ BMkAn3kqwxtZ/3wfXKjn6H9pM5xDB3fR =PkLF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Sr Unix Admin needed
You should post to the DC-SAGE mailing list. Trevor On Wed, Nov 17, 2010 at 6:19 PM, Mohamed Lrhazi wrote: > We are committed to deploying puppet and using it as our main tool for > managing all our systems but we are far from having fully deployed > it... > > The person we would hire would be expected to join all our efforts, > not just puppet deployment and management, but of course, puppet > knowledge and experience would be very highly appreciated. > > Thanks a lot for your interest and please email me directly if you > have further questions. > > Mohamed. > > On Wed, Nov 17, 2010 at 5:35 PM, Daniel Pittman wrote: >> Mohamed Lrhazi writes: >> >>> Sorry to use this list for a job ad... >>> >>> I work for a prestigious University in Washington, DC... and we are >>> looking, pretty urgently, for a senior Unix admin to join our team... >>> >>> Please contact me if you live in the area and are seriously >>> interested, and are seriously a Senior Unix person. >> >> Would we be right in understanding that y'all are fairly heavily invested in >> puppet, then, and the person you hired would be working with puppet as a >> routine and significant part of the job? >> >> Daniel >> -- >> ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 >> 707 >> ♽ made with 100 percent post-consumer electrons >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@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. >> >> > > > > -- > -- > If not for coffee, I'd have no use for water at all. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: bootstrapping facts
I am delivering the fact with pluginsync, but that will not have
occurred yet on bootstrap because puppet has yet to run for the first
time and deliver the fact. At least that is what I think is happening.
If I do a run that does not include the class referencing the fact
first, it will work fine on subsequent runs.
Here is the fact, in case it is relevant:
Facter.add("gw_init_script_exists") do
setcode do
FileTest.exist?("/etc/init.d/ublipgw.sh")
end
end
On Nov 17, 8:48 pm, Nigel Kersten wrote:
> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt wrote:
> > I am using a fact inside of a template. The problem I am running into
> > is that the bootstrap run of puppet fails with the following error:
>
> > err: Could not retrieve catalog from remote server: Error 400 on
> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
> > manifests/classes/base_gateway/manifests/init.pp:35
>
> > because the facts do not exist yet. I have worked around this by
> > placing an if statement around the resource that renders the template
> > like so:
>
> > if $gw_init_script_exists {
>
> > file { "/etc/monit.d/ublip_gw.monitrc":
> > content => template("base_gateway/ublip_gw.monitrc.erb"),
> > }
>
> > }
>
> > While this works it is not a very elegant solution. Is there a better
> > way of dealing with this situation?
>
> Why doesn't the fact exist yet?
>
> Are you delivering a fact via pluginsync, but that fact itself relies
> upon an executable script that you're delivering with Puppet ?
>
> Can you post the fact itself?
>
>
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/puppet-users?hl=en.
>
> --
> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] use current array element when declaring multiple resources using an array
On 11/10/2010 05:16 PM, Gabriel Filion wrote:
> On 11/10/2010 10:18 AM, luke.bigum wrote:
>> Hi list,
>>
>> When declaring multiple resources at once with an array like this:
>>
>> file { [ "foo", "bar" ]: ... }
>>
>> Is there a way to access the current array element so as to pass this
>> value as a parameter? So the "foo" resource has a parameter value
>> "foo" and "bar" with a parameter value "bar"?
>
>
> I think what you want is to use $name. it corresponds to the resource
> name that is currently being worked on.
>
> file { [ "foo", "bar" ]: path => "/blah/${name}.txt", ... }
>
Close, but no cigar.
You need to wrap the file in a define like:
define my_file() {
file { "$name":
owner => $name,
mode => 640,
}
}
Then you can just use
$array = [ ... ]
my_file { $array: }
Regards,
Felix
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Stopping a service before a package upgrade
Hi, On Thu, Nov 18, 2010 at 4:09 AM, Daniel Pittman wrote: > That wouldn't actually help: the package provider and the service provider > would need to collude, and Puppet doesn't really support that. > I forgot runit made things simpler, by having runit-policy.d which would prevent a service to start when a package is installed. Maybe something similar for monit ? A monit provider would still be required/nice-to-have to facilitate the procedure. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] trying to push a whole directory...
Hi,
On 18/11/10 03:06, Eric Sorenson wrote:
> Note I also changed your 'recurse => true' to 'recurse => remote', a sadly
> under-documented feature which eases recursive copies by recursing the source
> directory to build a list of files that need checksumming, not the target.
> (see http://projects.puppetlabs.com/issues/show/1469 for the backstory)
Just to abstract out the bit which is useful to anyone wanting to try this, this
describes what was implemented, right?
http://projects.puppetlabs.com/issues/1469#note-6
> If we want to go this way, the following would IMHO be preferable:
>
> ... recurse => ,
> recurselimit => [0-9]+
>
> Where:
>
> recurse parameter:
> both => old behavior
> remote => new behavior (recurse on master, prune on local)
> true => same as both
> false => default (ie no-recurse)
> [0-9]+ => both, but limit recursion, give a warning to user that
>this syntax is deprecated and that they should
>move to recurselimit.
>
> recurselimit parameter:
> [0-9]+ => recursion limit, usable with both (or true) and remote.
>If recurse=false it is ignored. If recurse is a number,
>then an error should be raised.
>
> This way, we preserve the old behavior by default and we warn people
> that the syntax is deprecated.
Now, it says it's fixed in 25.0? ("Affected version" means the broken version,
correct?)
Presumably this is the server version? (Be nice if that could be made explicit
in general.)
My question is then, given that version on the puppetmaster, what version
*clients* will this work with? For example, I have Ubuntu Lucid with
puppetmaster v25.4 and a Debian Lenny puppet client I'm testing, with v24.5.
N
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: bootstrapping facts
On Thu, Nov 18, 2010 at 6:46 AM, byron appelt wrote:
> I am delivering the fact with pluginsync, but that will not have
> occurred yet on bootstrap because puppet has yet to run for the first
> time and deliver the fact. At least that is what I think is happening.
> If I do a run that does not include the class referencing the fact
> first, it will work fine on subsequent runs.
That's not the case Byron.
When the client starts a run, it does a pluginsync, which will bring
down facts, types and providers.
The facts are then evaluated, and sent to the server in the same run.
Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
Something that may not be obvious is that your current fact returns a
boolean. Right now I suggest to people that they make all their facts
strings, and for booleans, return the strings "true" or "false".
If that file doesn't exist, $gw_init_script_exists will not have a
value, thus the template will error. Until Facter supports rich data
types, you should return a string.
>
> Here is the fact, in case it is relevant:
>
> Facter.add("gw_init_script_exists") do
> setcode do
> FileTest.exist?("/etc/init.d/ublipgw.sh")
> end
> end
>
> On Nov 17, 8:48 pm, Nigel Kersten wrote:
>> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt wrote:
>> > I am using a fact inside of a template. The problem I am running into
>> > is that the bootstrap run of puppet fails with the following error:
>>
>> > err: Could not retrieve catalog from remote server: Error 400 on
>> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
>> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
>> > manifests/classes/base_gateway/manifests/init.pp:35
>>
>> > because the facts do not exist yet. I have worked around this by
>> > placing an if statement around the resource that renders the template
>> > like so:
>>
>> > if $gw_init_script_exists {
>>
>> > file { "/etc/monit.d/ublip_gw.monitrc":
>> > content => template("base_gateway/ublip_gw.monitrc.erb"),
>> > }
>>
>> > }
>>
>> > While this works it is not a very elegant solution. Is there a better
>> > way of dealing with this situation?
>>
>> Why doesn't the fact exist yet?
>>
>> Are you delivering a fact via pluginsync, but that fact itself relies
>> upon an executable script that you're delivering with Puppet ?
>>
>> Can you post the fact itself?
>>
>>
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Puppet Users" group.
>> > To post to this group, send email to puppet-us...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/puppet-users?hl=en.
>>
>> --
>> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Multiple CA / Puppet master environment
I think it's a bad idea to deal with the overhead of an NFS mount when you have a dedicated puppet CA, as on your non-CA servers there should be no need to ever write to that directory. On Wed, Nov 17, 2010 at 7:55 PM, Scott Smith wrote: > Oh, that's for sharing the puppetmaster SSL keypair between each other, > that's all. > > On Nov 17, 2010 3:53 PM, "Nigel Kersten" wrote: >> On Wed, Nov 17, 2010 at 1:29 PM, Scott Smith wrote: >>> nfs mount the puppetmaster ssl dir. seperate puppetca (set on clients) >>> play >>> with it and you'll figure it out :) >> >> Why do you need to nfs mount the puppetmaster SSL dir in this case Scott? >> >> There's no state to be shared if you're operating with a dedicated >> puppetca. >> >> >> >>> >>> On Nov 11, 2010 9:18 AM, "luke.bigum" wrote: Hi, Does anyone know if this document is up to date (besides the comment at the top saying it's not): http://projects.puppetlabs.com/projects/1/wiki/Multiple_Certificate_Authorities Or does anyone who has a load balanced multi puppet master with some kind of shared CA confirm that the procedure is accurate? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-us...@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. >>> >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > -- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Of classes, tags, and collections
On Nov 18, 1:56 am, Ian Ward Comfort wrote:
> On 18 Nov 2010, at 1:06 AM, Owen Smith wrote:
> >
> > class testa {
> > notify {
> > "note_testa": message => "Test A!";
> > "note2_testa": message => "Test A take 2!"
> > }
> > }
>
> > class testb {
> > notify { "note_testb": message => "Test B!" }
> > }
> >
> > Notify<| tag == "testb" |> -> Notify<| tag == "testa" |>
> >
> > node puptest {
> > include testa
> > include testb
> > }
> > -
> >
> > ...I would expect
> > to see the following relationships represented:
>
> > Notify[note_testb] -> Notify[note_testa]
> > Notify[note_testb] -> Notify[note2_testa]
> >
> > However, I'm not seeing any relationships between the notifies at all
> > - the graph is disjoint, and the messages appear in any order.
>
> You may be running across something as simple as a slight variation on bug
> #4560:
>
> https://projects.puppetlabs.com/issues/4560
>
> In short, implicit tag assignment does not seem to be reliable.
Good call! Putting explicit tag declarations on the resources fixes
the problem. Though the purpose here was to simplify my resource
declarations and factor out certain releationships as a separate
aspect, so this workaround doesn't buy me much.
Given that, I'll call this a bug, and I'll note the relationship to
the issue above. (It's a related issue but different because I'm not
dealing with virtual resources.)
Thanks!
-- O
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: bootstrapping facts
I'm sure I don't understand something here, but when I look at the
value of the facts on the puppetmaster, they are strings and some of
them are false. I know the fact is coded to return a boolean, but I
assumed there is a to_s occurring somewhere along the way. See below
(hostnames altered to protect the innocent)
r...@puppetmaster:/var/lib/puppet/yaml/facts# grep init *
xxx1.numerexfast.com.yaml: gw_init_script_exists: "true"
xxx2.numerexfast.com.yaml: gw_init_script_exists: "true"
xxx3.numerexfast.com.yaml: gw_init_script_exists: "false"
xxx4.numerexfast.com.yaml: gw_init_script_exists: "true"
xxx5.numerex.com.yaml: gw_init_script_exists: "false"
Doesn't this mean that the fact has a value even if the file does not
exist? I will try your suggestion of returning a string explicitly to
see if that is in fact the problem.
-Byron
On Nov 18, 10:59 am, Nigel Kersten wrote:
> On Thu, Nov 18, 2010 at 6:46 AM, byron appelt wrote:
> > I am delivering the fact with pluginsync, but that will not have
> > occurred yet on bootstrap because puppet has yet to run for the first
> > time and deliver the fact. At least that is what I think is happening.
> > If I do a run that does not include the class referencing the fact
> > first, it will work fine on subsequent runs.
>
> That's not the case Byron.
>
> When the client starts a run, it does a pluginsync, which will bring
> down facts, types and providers.
>
> The facts are then evaluated, and sent to the server in the same run.
>
> Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
>
> Something that may not be obvious is that your current fact returns a
> boolean. Right now I suggest to people that they make all their facts
> strings, and for booleans, return the strings "true" or "false".
>
> If that file doesn't exist, $gw_init_script_exists will not have a
> value, thus the template will error. Until Facter supports rich data
> types, you should return a string.
>
>
>
>
>
>
>
>
>
>
>
> > Here is the fact, in case it is relevant:
>
> > Facter.add("gw_init_script_exists") do
> > setcode do
> > FileTest.exist?("/etc/init.d/ublipgw.sh")
> > end
> > end
>
> > On Nov 17, 8:48 pm, Nigel Kersten wrote:
> >> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt
> >> wrote:
> >> > I am using a fact inside of a template. The problem I am running into
> >> > is that the bootstrap run of puppet fails with the following error:
>
> >> > err: Could not retrieve catalog from remote server: Error 400 on
> >> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
> >> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
> >> > manifests/classes/base_gateway/manifests/init.pp:35
>
> >> > because the facts do not exist yet. I have worked around this by
> >> > placing an if statement around the resource that renders the template
> >> > like so:
>
> >> > if $gw_init_script_exists {
>
> >> > file { "/etc/monit.d/ublip_gw.monitrc":
> >> > content => template("base_gateway/ublip_gw.monitrc.erb"),
> >> > }
>
> >> > }
>
> >> > While this works it is not a very elegant solution. Is there a better
> >> > way of dealing with this situation?
>
> >> Why doesn't the fact exist yet?
>
> >> Are you delivering a fact via pluginsync, but that fact itself relies
> >> upon an executable script that you're delivering with Puppet ?
>
> >> Can you post the fact itself?
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Puppet Users" group.
> >> > To post to this group, send email to puppet-us...@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > puppet-users+unsubscr...@googlegroups.com.
> >> > For more options, visit this group
> >> > athttp://groups.google.com/group/puppet-users?hl=en.
>
> >> --
> >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/puppet-users?hl=en.
>
> --
> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: bootstrapping facts
On Thu, Nov 18, 2010 at 10:04 AM, byron appelt wrote:
> I'm sure I don't understand something here, but when I look at the
> value of the facts on the puppetmaster, they are strings and some of
> them are false. I know the fact is coded to return a boolean, but I
> assumed there is a to_s occurring somewhere along the way. See below
> (hostnames altered to protect the innocent)
>
> r...@puppetmaster:/var/lib/puppet/yaml/facts# grep init *
>
> xxx1.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx2.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx3.numerexfast.com.yaml: gw_init_script_exists: "false"
> xxx4.numerexfast.com.yaml: gw_init_script_exists: "true"
> xxx5.numerex.com.yaml: gw_init_script_exists: "false"
>
> Doesn't this mean that the fact has a value even if the file does not
> exist? I will try your suggestion of returning a string explicitly to
> see if that is in fact the problem.
I've just been informed that we did at some point start converting all
facts to strings, but that there have been some edge cases where this
didn't necessarily happen.
It looks like you're not suffering that, so I must have pointed you in
the wrong direction.
When you run the client in debug/verbose mode, are you seeing the
custom fact get synced down at the start of the run, and then sent up
to the server?
>
> -Byron
>
> On Nov 18, 10:59 am, Nigel Kersten wrote:
>> On Thu, Nov 18, 2010 at 6:46 AM, byron appelt wrote:
>> > I am delivering the fact with pluginsync, but that will not have
>> > occurred yet on bootstrap because puppet has yet to run for the first
>> > time and deliver the fact. At least that is what I think is happening.
>> > If I do a run that does not include the class referencing the fact
>> > first, it will work fine on subsequent runs.
>>
>> That's not the case Byron.
>>
>> When the client starts a run, it does a pluginsync, which will bring
>> down facts, types and providers.
>>
>> The facts are then evaluated, and sent to the server in the same run.
>>
>> Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
>>
>> Something that may not be obvious is that your current fact returns a
>> boolean. Right now I suggest to people that they make all their facts
>> strings, and for booleans, return the strings "true" or "false".
>>
>> If that file doesn't exist, $gw_init_script_exists will not have a
>> value, thus the template will error. Until Facter supports rich data
>> types, you should return a string.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > Here is the fact, in case it is relevant:
>>
>> > Facter.add("gw_init_script_exists") do
>> > setcode do
>> > FileTest.exist?("/etc/init.d/ublipgw.sh")
>> > end
>> > end
>>
>> > On Nov 17, 8:48 pm, Nigel Kersten wrote:
>> >> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt
>> >> wrote:
>> >> > I am using a fact inside of a template. The problem I am running into
>> >> > is that the bootstrap run of puppet fails with the following error:
>>
>> >> > err: Could not retrieve catalog from remote server: Error 400 on
>> >> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
>> >> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
>> >> > manifests/classes/base_gateway/manifests/init.pp:35
>>
>> >> > because the facts do not exist yet. I have worked around this by
>> >> > placing an if statement around the resource that renders the template
>> >> > like so:
>>
>> >> > if $gw_init_script_exists {
>>
>> >> > file { "/etc/monit.d/ublip_gw.monitrc":
>> >> > content => template("base_gateway/ublip_gw.monitrc.erb"),
>> >> > }
>>
>> >> > }
>>
>> >> > While this works it is not a very elegant solution. Is there a better
>> >> > way of dealing with this situation?
>>
>> >> Why doesn't the fact exist yet?
>>
>> >> Are you delivering a fact via pluginsync, but that fact itself relies
>> >> upon an executable script that you're delivering with Puppet ?
>>
>> >> Can you post the fact itself?
>>
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Puppet Users" group.
>> >> > To post to this group, send email to puppet-us...@googlegroups.com.
>> >> > To unsubscribe from this group, send email to
>> >> > puppet-users+unsubscr...@googlegroups.com.
>> >> > For more options, visit this group
>> >> > athttp://groups.google.com/group/puppet-users?hl=en.
>>
>> >> --
>> >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Puppet Users" group.
>> > To post to this group, send email to puppet-us...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/puppet-users?hl=en.
>>
>> --
>> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>
> --
> You received this message because you are subscribed to
Re: [Puppet Users] Can't get plugins in modules with environments to work in 2.6
On Wed, Nov 17, 2010 at 9:14 PM, Patrick wrote: > I think I heard somewhere that pluginsync ignores environments. This is absolutely not true in the last two major versions of Puppet. You may have been thinking about how plugins-in-modules didn't work particularly well with environments in 0.24.x days, but since 0.25.x it has definitely been supported. When the client has a certain environment specified, it connects to the master, and pluginsyncs the $modulepath/*/lib/... plugins for that environment. > > On Nov 17, 2010, at 8:27 PM, John Warburton wrote: > > Hi All > > I'm quite prepared to acknowledge I've missed the bleeding obvious here, but > I just can't see. Hence the post > > I am getting the exact same errors as issue 4409 > (http://projects.puppetlabs.com/issues/4409) when trying to use a type in a > module in an environment > > When the type is in /modules/testmodule/lib/puppet/type, I get > this error message: > > err: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid > resource type logadm at > /tmp/puppet26/environments/prod/modules/testmodule/manifests/init.pp:15 on > node corwadm010.bfm.com > > When I copy it to $libdir/puppet/type on the server - it works, which > ignores the environments :-( > > I have updated http://projects.puppetlabs.com/issues/4409 with my test case > - fresh independent 2.6.3 install - config files, client & server debug > output (from Markus Robert's diagnostic patch) in > http://projects.puppetlabs.com/attachments/1227/issue4409.txt > > I am sure I am missing something - as > http://projects.puppetlabs.com/issues/1175 says it was all fixed for 2.6 > > Thanks for any pointers > > Regards > > John > > References: > http://docs.puppetlabs.com/guides/custom_types.html > http://docs.puppetlabs.com/guides/environment.html > http://docs.puppetlabs.com/guides/plugins_in_modules.html > http://projects.puppetlabs.com/issues/1175 > http://projects.puppetlabs.com/issues/4409 > https://github.com/MarkusQ/puppet/tree/ticket/2.6.x/4409 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > -- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] test - please ignore
Apologies -- the last two messages I sent to the list have not appeared ... -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: more errors with pushig out directories
On Nov 19, 3:22 am, jcbollinger wrote: > Oops, sorry for the empty post. > > On Nov 17, 8:50 pm, kiwi wrote: > > > Any idea what is wrong here? > > Could it simply be that you have misspelled 'monitor' in your > resource's "source" property? Doh!!! I spent hours looking at that! I thought I had tested it by cutting and pasting the path into shell -- clearly not.I can't even plead lack of caffeine. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Multiple CA / Puppet master environment
Puppetmasters (the puppetmasterds serving catalogs) don't need access to the same SSL dir the Puppet CA (the puppetmasterd signing and revoking certs). But, they do need to share the private key for presenting the certificate for puppet.domain.com. And the CRL as well, if you use it. That directory doesn't have to be shared via NFS. You could rsync the ssl directory between your puppetmasters. On Thu, Nov 18, 2010 at 9:00 AM, Nigel Kersten wrote: > I think it's a bad idea to deal with the overhead of an NFS mount when > you have a dedicated puppet CA, as on your non-CA servers there should > be no need to ever write to that directory. > > > On Wed, Nov 17, 2010 at 7:55 PM, Scott Smith wrote: > > Oh, that's for sharing the puppetmaster SSL keypair between each other, > > that's all. > > > > On Nov 17, 2010 3:53 PM, "Nigel Kersten" wrote: > >> On Wed, Nov 17, 2010 at 1:29 PM, Scott Smith wrote: > >>> nfs mount the puppetmaster ssl dir. seperate puppetca (set on clients) > >>> play > >>> with it and you'll figure it out :) > >> > >> Why do you need to nfs mount the puppetmaster SSL dir in this case > Scott? > >> > >> There's no state to be shared if you're operating with a dedicated > >> puppetca. > >> > >> > >> > >>> > >>> On Nov 11, 2010 9:18 AM, "luke.bigum" > wrote: > Hi, > > Does anyone know if this document is up to date (besides the comment > at the top saying it's not): > > > > > http://projects.puppetlabs.com/projects/1/wiki/Multiple_Certificate_Authorities > > Or does anyone who has a load balanced multi puppet master with some > kind of shared CA confirm that the procedure is accurate? > > -- > You received this message because you are subscribed to the Google > Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Puppet Users" group. > >>> To post to this group, send email to puppet-us...@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. > >>> > >> > >> > >> > >> -- > >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Users" group. > >> To post to this group, send email to puppet-us...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscr...@googlegroups.com > . > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-users?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-us...@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. > > > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > > -- http://about.me/scoot http://twitter.com/ohlol -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] DEPRECATION WARNING
Hello All, Is there a way of suppressing DEPRECATION WARNINGS? Ever since I upgraded rails, I keep on getting deprecation warnings that I run puppetd. Is there any way of turning these off? i.e, ruby --version ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-linux] puppet --version DEPRECATION WARNING: metaclass is deprecated and will be removed from Rails 2.3 (use singleton_class instead). (called from meta_eval at / usr/lib/ruby/site_ruby/1.8/puppet/util/metaid.rb:4) 0.25.5 cat /etc/redhat-release CentOS release 5.5 (Final) Thanks, Henry -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: bootstrapping facts
I figured it out. I do not see the facts being synced on the bootstrap
run and I no know why. Since I am using puppet to configure itself,
there is no puppet.conf on the bootstrap run and therefore no
pluginsync=true. I just have to do the bootstrap run with the --
pluginsync option and all is well now.
Thanks for all your help Nigel, I would not have figured it out alone.
-Byron
On Nov 18, 1:03 pm, Nigel Kersten wrote:
> On Thu, Nov 18, 2010 at 10:04 AM, byron appelt wrote:
> > I'm sure I don't understand something here, but when I look at the
> > value of the facts on the puppetmaster, they are strings and some of
> > them are false. I know the fact is coded to return a boolean, but I
> > assumed there is a to_s occurring somewhere along the way. See below
> > (hostnames altered to protect the innocent)
>
> > r...@puppetmaster:/var/lib/puppet/yaml/facts# grep init *
>
> > xxx1.numerexfast.com.yaml: gw_init_script_exists: "true"
> > xxx2.numerexfast.com.yaml: gw_init_script_exists: "true"
> > xxx3.numerexfast.com.yaml: gw_init_script_exists: "false"
> > xxx4.numerexfast.com.yaml: gw_init_script_exists: "true"
> > xxx5.numerex.com.yaml: gw_init_script_exists: "false"
>
> > Doesn't this mean that the fact has a value even if the file does not
> > exist? I will try your suggestion of returning a string explicitly to
> > see if that is in fact the problem.
>
> I've just been informed that we did at some point start converting all
> facts to strings, but that there have been some edge cases where this
> didn't necessarily happen.
>
> It looks like you're not suffering that, so I must have pointed you in
> the wrong direction.
>
> When you run the client in debug/verbose mode, are you seeing the
> custom fact get synced down at the start of the run, and then sent up
> to the server?
>
>
>
>
>
>
>
>
>
>
>
> > -Byron
>
> > On Nov 18, 10:59 am, Nigel Kersten wrote:
> >> On Thu, Nov 18, 2010 at 6:46 AM, byron appelt
> >> wrote:
> >> > I am delivering the fact with pluginsync, but that will not have
> >> > occurred yet on bootstrap because puppet has yet to run for the first
> >> > time and deliver the fact. At least that is what I think is happening.
> >> > If I do a run that does not include the class referencing the fact
> >> > first, it will work fine on subsequent runs.
>
> >> That's not the case Byron.
>
> >> When the client starts a run, it does a pluginsync, which will bring
> >> down facts, types and providers.
>
> >> The facts are then evaluated, and sent to the server in the same run.
>
> >> Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
>
> >> Something that may not be obvious is that your current fact returns a
> >> boolean. Right now I suggest to people that they make all their facts
> >> strings, and for booleans, return the strings "true" or "false".
>
> >> If that file doesn't exist, $gw_init_script_exists will not have a
> >> value, thus the template will error. Until Facter supports rich data
> >> types, you should return a string.
>
> >> > Here is the fact, in case it is relevant:
>
> >> > Facter.add("gw_init_script_exists") do
> >> > setcode do
> >> > FileTest.exist?("/etc/init.d/ublipgw.sh")
> >> > end
> >> > end
>
> >> > On Nov 17, 8:48 pm, Nigel Kersten wrote:
> >> >> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt
> >> >> wrote:
> >> >> > I am using a fact inside of a template. The problem I am running into
> >> >> > is that the bootstrap run of puppet fails with the following error:
>
> >> >> > err: Could not retrieve catalog from remote server: Error 400 on
> >> >> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
> >> >> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
> >> >> > manifests/classes/base_gateway/manifests/init.pp:35
>
> >> >> > because the facts do not exist yet. I have worked around this by
> >> >> > placing an if statement around the resource that renders the template
> >> >> > like so:
>
> >> >> > if $gw_init_script_exists {
>
> >> >> > file { "/etc/monit.d/ublip_gw.monitrc":
> >> >> > content => template("base_gateway/ublip_gw.monitrc.erb"),
> >> >> > }
>
> >> >> > }
>
> >> >> > While this works it is not a very elegant solution. Is there a better
> >> >> > way of dealing with this situation?
>
> >> >> Why doesn't the fact exist yet?
>
> >> >> Are you delivering a fact via pluginsync, but that fact itself relies
> >> >> upon an executable script that you're delivering with Puppet ?
>
> >> >> Can you post the fact itself?
>
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> >> >> > Groups "Puppet Users" group.
> >> >> > To post to this group, send email to puppet-us...@googlegroups.com.
> >> >> > To unsubscribe from this group, send email to
> >> >> > puppet-users+unsubscr...@googlegroups.com.
> >> >> > For more options, visit this group
> >> >> > athttp://groups.google.com/group/puppet-users?hl=en.
>
> >> >> --
> >> >> Nigel Kersten
Re: [Puppet Users] Re: bootstrapping facts
On Thu, Nov 18, 2010 at 12:21 PM, byron appelt wrote:
> I figured it out. I do not see the facts being synced on the bootstrap
> run and I no know why. Since I am using puppet to configure itself,
> there is no puppet.conf on the bootstrap run and therefore no
> pluginsync=true. I just have to do the bootstrap run with the --
> pluginsync option and all is well now.
>
> Thanks for all your help Nigel, I would not have figured it out alone.
No worries. Glad you worked it out.
Ideally we'd like to be able to move to pluginsync by default, but
there are a few issues around this that need to be resolved before we
can do that.
>
> -Byron
>
> On Nov 18, 1:03 pm, Nigel Kersten wrote:
>> On Thu, Nov 18, 2010 at 10:04 AM, byron appelt
>> wrote:
>> > I'm sure I don't understand something here, but when I look at the
>> > value of the facts on the puppetmaster, they are strings and some of
>> > them are false. I know the fact is coded to return a boolean, but I
>> > assumed there is a to_s occurring somewhere along the way. See below
>> > (hostnames altered to protect the innocent)
>>
>> > r...@puppetmaster:/var/lib/puppet/yaml/facts# grep init *
>>
>> > xxx1.numerexfast.com.yaml: gw_init_script_exists: "true"
>> > xxx2.numerexfast.com.yaml: gw_init_script_exists: "true"
>> > xxx3.numerexfast.com.yaml: gw_init_script_exists: "false"
>> > xxx4.numerexfast.com.yaml: gw_init_script_exists: "true"
>> > xxx5.numerex.com.yaml: gw_init_script_exists: "false"
>>
>> > Doesn't this mean that the fact has a value even if the file does not
>> > exist? I will try your suggestion of returning a string explicitly to
>> > see if that is in fact the problem.
>>
>> I've just been informed that we did at some point start converting all
>> facts to strings, but that there have been some edge cases where this
>> didn't necessarily happen.
>>
>> It looks like you're not suffering that, so I must have pointed you in
>> the wrong direction.
>>
>> When you run the client in debug/verbose mode, are you seeing the
>> custom fact get synced down at the start of the run, and then sent up
>> to the server?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > -Byron
>>
>> > On Nov 18, 10:59 am, Nigel Kersten wrote:
>> >> On Thu, Nov 18, 2010 at 6:46 AM, byron appelt
>> >> wrote:
>> >> > I am delivering the fact with pluginsync, but that will not have
>> >> > occurred yet on bootstrap because puppet has yet to run for the first
>> >> > time and deliver the fact. At least that is what I think is happening.
>> >> > If I do a run that does not include the class referencing the fact
>> >> > first, it will work fine on subsequent runs.
>>
>> >> That's not the case Byron.
>>
>> >> When the client starts a run, it does a pluginsync, which will bring
>> >> down facts, types and providers.
>>
>> >> The facts are then evaluated, and sent to the server in the same run.
>>
>> >> Are you delivering the file "/etc/init.d/ublipgw.sh" with Puppet?
>>
>> >> Something that may not be obvious is that your current fact returns a
>> >> boolean. Right now I suggest to people that they make all their facts
>> >> strings, and for booleans, return the strings "true" or "false".
>>
>> >> If that file doesn't exist, $gw_init_script_exists will not have a
>> >> value, thus the template will error. Until Facter supports rich data
>> >> types, you should return a string.
>>
>> >> > Here is the fact, in case it is relevant:
>>
>> >> > Facter.add("gw_init_script_exists") do
>> >> > setcode do
>> >> > FileTest.exist?("/etc/init.d/ublipgw.sh")
>> >> > end
>> >> > end
>>
>> >> > On Nov 17, 8:48 pm, Nigel Kersten wrote:
>> >> >> On Wed, Nov 17, 2010 at 1:05 PM, byron appelt
>> >> >> wrote:
>> >> >> > I am using a fact inside of a template. The problem I am running into
>> >> >> > is that the bootstrap run of puppet fails with the following error:
>>
>> >> >> > err: Could not retrieve catalog from remote server: Error 400 on
>> >> >> > SERVER: Failed to parse template base_gateway/ublip_gw.monitrc.erb:
>> >> >> > Could not find value for 'gw_init_script_exists' at /etc/puppet-dev/
>> >> >> > manifests/classes/base_gateway/manifests/init.pp:35
>>
>> >> >> > because the facts do not exist yet. I have worked around this by
>> >> >> > placing an if statement around the resource that renders the template
>> >> >> > like so:
>>
>> >> >> > if $gw_init_script_exists {
>>
>> >> >> > file { "/etc/monit.d/ublip_gw.monitrc":
>> >> >> > content => template("base_gateway/ublip_gw.monitrc.erb"),
>> >> >> > }
>>
>> >> >> > }
>>
>> >> >> > While this works it is not a very elegant solution. Is there a better
>> >> >> > way of dealing with this situation?
>>
>> >> >> Why doesn't the fact exist yet?
>>
>> >> >> Are you delivering a fact via pluginsync, but that fact itself relies
>> >> >> upon an executable script that you're delivering with Puppet ?
>>
>> >> >> Can you post the fact itself?
>>
>> >> >> > --
>> >> >> > You received this message because you are subscribed to th
Re: [Puppet Users] Multiple CA / Puppet master environment
On Thu, Nov 18, 2010 at 12:01 PM, Scott Smith wrote: > Puppetmasters (the puppetmasterds serving catalogs) don't need access to the > same SSL dir the Puppet CA (the puppetmasterd signing and revoking certs). > But, they do need to share the private key for presenting the certificate > for puppet.domain.com. And the CRL as well, if you use it. That directory > doesn't have to be shared via NFS. You could rsync the ssl directory between > your puppetmasters. Absolutely. I just try to avoid NFS where possible. > > On Thu, Nov 18, 2010 at 9:00 AM, Nigel Kersten wrote: >> >> I think it's a bad idea to deal with the overhead of an NFS mount when >> you have a dedicated puppet CA, as on your non-CA servers there should >> be no need to ever write to that directory. >> >> >> On Wed, Nov 17, 2010 at 7:55 PM, Scott Smith wrote: >> > Oh, that's for sharing the puppetmaster SSL keypair between each other, >> > that's all. >> > >> > On Nov 17, 2010 3:53 PM, "Nigel Kersten" wrote: >> >> On Wed, Nov 17, 2010 at 1:29 PM, Scott Smith wrote: >> >>> nfs mount the puppetmaster ssl dir. seperate puppetca (set on clients) >> >>> play >> >>> with it and you'll figure it out :) >> >> >> >> Why do you need to nfs mount the puppetmaster SSL dir in this case >> >> Scott? >> >> >> >> There's no state to be shared if you're operating with a dedicated >> >> puppetca. >> >> >> >> >> >> >> >>> >> >>> On Nov 11, 2010 9:18 AM, "luke.bigum" >> >>> wrote: >> Hi, >> >> Does anyone know if this document is up to date (besides the comment >> at the top saying it's not): >> >> >> >> >> http://projects.puppetlabs.com/projects/1/wiki/Multiple_Certificate_Authorities >> >> Or does anyone who has a load balanced multi puppet master with some >> kind of shared CA confirm that the procedure is accurate? >> >> -- >> You received this message because you are subscribed to the Google >> Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> >>> Groups >> >>> "Puppet Users" group. >> >>> To post to this group, send email to puppet-us...@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. >> >>> >> >> >> >> >> >> >> >> -- >> >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Puppet Users" group. >> >> To post to this group, send email to puppet-us...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscr...@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-us...@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. >> > >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@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. >> > > > > -- > http://about.me/scoot > http://twitter.com/ohlol > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > -- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] trying to push a whole directory...
On Thu, Nov 18, 2010 at 1:45 AM, Nick wrote:
> Hi,
>
> On 18/11/10 03:06, Eric Sorenson wrote:
>> Note I also changed your 'recurse => true' to 'recurse => remote', a sadly
>> under-documented feature which eases recursive copies by recursing the source
>> directory to build a list of files that need checksumming, not the target.
>> (see http://projects.puppetlabs.com/issues/show/1469 for the backstory)
>
> Just to abstract out the bit which is useful to anyone wanting to try this,
> this
> describes what was implemented, right?
>
> http://projects.puppetlabs.com/issues/1469#note-6
>> If we want to go this way, the following would IMHO be preferable:
>>
>> ... recurse => ,
>> recurselimit => [0-9]+
>>
>> Where:
>>
>> recurse parameter:
>> both => old behavior
>> remote => new behavior (recurse on master, prune on local)
>> true => same as both
>> false => default (ie no-recurse)
>> [0-9]+ => both, but limit recursion, give a warning to user that
>> this syntax is deprecated and that they should
>> move to recurselimit.
>>
>> recurselimit parameter:
>> [0-9]+ => recursion limit, usable with both (or true) and remote.
>> If recurse=false it is ignored. If recurse is a number,
>> then an error should be raised.
>>
>> This way, we preserve the old behavior by default and we warn people
>> that the syntax is deprecated.
>
>
> Now, it says it's fixed in 25.0? ("Affected version" means the broken
> version,
> correct?)
>
> Presumably this is the server version? (Be nice if that could be made
> explicit
> in general.)
>
> My question is then, given that version on the puppetmaster, what version
> *clients* will this work with? For example, I have Ubuntu Lucid with
> puppetmaster v25.4 and a Debian Lenny puppet client I'm testing, with v24.5.
This is a really good question. We need to more clearly specify
required client and server versions for new functionality.
I'm pretty sure you're going to need 0.25.x on both the server and
client to get this functionality.
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Managing private key files; content=>file vs. binary content.
On 11.11.2010 11:06, Chris wrote: In the general case, even completely legitimate (and common) Latin-1 text files can cause Puppet problems because some Latin-1 bytes are not valid UTF-8. In my opinion, the content parameter of a file resource should be able to handle these cases. I think you should file a bug then. I've raised http://projects.puppetlabs.com/issues/5261 Thinking back to the original PSON bug, the workaround back then was to use YAML serialization. I did notice that that could make clients crash though, I think the 0.25.5 were the afflicted ones. You may want to give it shot though, anyway. The YAML encoder seems to be less picky where encodings are concerned. Regards, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: client won't use remote file bucket
On 09.11.2010 10:33, luke.bigum wrote:
Roman,
Not that I know of. I'm still aware it doesn't work in my site, but
I'm content with local file bucketing until I have the time to look at
this again.
-Luke
On Nov 9, 3:47 am, Roman wrote:
Hi James.
Could you tell if you found a resolution to this problem? I seem to
experience it as well.
Thanks in advance,
Regards,
Roman
On Oct 20, 2:31 am, "luke.bigum" wrote:
Hi all,
I'm having a stupid moment getting a remote file bucket working. My
client only file buckets locally, not remotely.
I have this site.pp:
*
filebucket { "main": server => "puppet" }
File { backup => "main" }
node 'default' {
include test}
All this rings a faint bell. We had a similar problem after upgrading to
0.25.5.
For us, specifying "path => false" in the filebucket { } solved the issue.
Let me know if it does anything for you.
HTH,
Felix
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@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] plusignment to add values to a resource several times
Hi,
Has any work been done or is any work being planned to allow plusignment
to add values to a resource several times?
This has been discussed before at
https://groups.google.com/group/puppet-users/browse_thread/thread/b276948477fa14ae
http://projects.puppetlabs.com/issues/2825
My immediate use case is the same as Bryan's in the previous discussion.
I would like to have puppet manage some users that represent human
beings that logged in to systems, and I need to be able to add them to
different combinations of groups on different systems. To make things
clearer, I'll paste Bryan's test case below.
node testnode {
include user::groupA
include user::groupB
}
class user::groupA inherits user::virtual {
User["bryan"] { groups +> "groupA" }
User["bob"] { groups +> "groupA" }
realize(
Group["groupA"],
User["bryan"],
User["bob"],
)
}
class user::groupB inherits user::virtual {
User["harry"] { groups +> "groupB" }
User["bryan"] { groups +> "groupB" }
realize(
Group["groupB"],
User["harry"],
User["bryan"],
)
}
class user::virtual {
@user { "bryan":
uid => 1001,
gid => 1001,
}
@user { "bob":
uid => 1002,
gid => 1002,
}
@user { "harry":
uid => 1003,
gid => 1003,
}
}
This fails with "Could not retrieve catalog: Parameter 'groups' is
already set on User[bryan] by user::groupA" in 0.24.8. I don't have a
newer puppet version to easily test with, unfortunately.
--
Brian Pitts
Systems Administrator | EuPathDB Bioinformatics Resource Center
706-542-1447 | b...@uga.edu | http://eupathdb.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-us...@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: preferred directory structure for multiple environments
On 12.11.2010 19:22, techn0gichida wrote: I found the problem in /etc/sysconfig/puppetmaster. The MANIFEST directive wasn't commented out. Shouldn't this be commented on that it needs to be commented out for multiple environment use? I don't really see your point. Yes, there is a commented out line in the posted config. Randomly commenting out such a line from your conf surely won't fix a problem you're having? Besides, theres a perfectly functional manifest= line just below it: [int] #modulepath = /etc/puppet/modules/int #manifest = /etc/puppet/manifests/int/site.pp manifest = /etc/puppet/int/site.pp modulepath = /etc/puppet/int/modules Regards, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Managing a "complex" directory structure
Hi,
I'm trying to manage our Hadoop cluster with Puppet but there are a
few challenges. The one I'm facing now is managing the following.
I've got an array variable depending on the type of server:
$hadoop_disks = ['/mnt/disk1', '/mnt/disk2', ...]
Depending on the classes I include for each role there needs to be a
different directory structure on all those disks.
Namenode + Datanode = /mnt/diskX/hadoop/dfs
Jobtracker + Tasktracker = /mnt/diskX/hadoop/mapred
Each directory (/hadoop, /hadoop/dfs, /hadoop/mapred) has different
permissions and both roles can be on the same server (Namenode +
Datanode).
I've tried multiple different things but I wasn't able to find a
solution that works. This is what I thought about doing:
base class:
define hadoop_main_directory() {
file { "${name}/hadoop":
ensure => directory,
owner => "root",
group => "hadoop",
}
}
define hadoop_sub_directory($path, $user) {
file { "${name}/hadoop/${path}":
ensure => directory,
owner => $user,
group => "hadoop",
require => Hadoop_main_directory[$name],
}
}
And in each of the four classes a definition like
hadoop_sub_directory { $hadoop_disks:
path=> "dfs",
owner => "hdfs",
}
But I guess that doesn't work because a resource may be managed multiple times.
Any ideas how to solve this? I can provide more details. Our
configuration is also on github[1] but it's not working right now and
probably not very pretty. First time I've used Puppet and learning on
the go...
Cheers,
Lars
[1] https://github.com/lfrancke/gbif-puppet
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: preferred directory structure for multiple environments
Don't know what to tell you. Commenting out the line in that file fixed the problem. And it's been working great since. On Thu, Nov 18, 2010 at 5:51 PM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote: > On 12.11.2010 19:22, techn0gichida wrote: > >> I found the problem in /etc/sysconfig/puppetmaster. The MANIFEST >> directive wasn't commented out. Shouldn't this be commented on that it >> needs to be commented out for multiple environment use? >> > > I don't really see your point. Yes, there is a commented out line in the > posted config. Randomly commenting out such a line from your conf surely > won't fix a problem you're having? > > Besides, theres a perfectly functional manifest= line just below it: > > > [int] >>> #modulepath = /etc/puppet/modules/int >>> #manifest = /etc/puppet/manifests/int/site.pp >>> manifest = /etc/puppet/int/site.pp >>> modulepath = /etc/puppet/int/modules >>> >> > Regards, > Felix > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > > -- “Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.” – Mark Twain -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] what are the constraints on the contents of 'imported ' files
I am trying to import a hash definition from a separate file but this
fails whereas including the text verbatim in the original manifest
works fine:
class monitor ($master, $interface) {
# import "masters.pp"
$sensor_rule_categories = {
'dmzo' =>
[scan,finger,ftp,telnet,rpc,rservices,ddos,dns,tftp,web-
coldfusion,misc,web-php,x11,attack-responses,
oracle,mysql,pop2,pop3,bad-
traffic,dos,exploit,misc,smtp,web-misc,emerging-exploit,emerging-scan,
emerging-web,emerging-web_sql_injection,emerging-
web_server,emerging-web_specific_apps,
emerging-attack_response,emerging-
virus,emerging,emerging-trojan]
}
$rule_files = $sensor_rule_categories[$master]
if I have the definition $sensor_rule_categories in the file ./
masters.pp then I get the error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: undefined local variable or method `accesskey' for
# at /etc/
puppet/modules/monitor/manifests/init.pp:19 on node
mon263550.insec.auckland.ac.nz
I really want to have this stuff in a separate file as it is generated
elsewhere I want to have a symlink to the file with the defs rather
than have to hack at init.pp itself.
I guess my real question is what are the constraints on the contents
of 'imported ' files?
Also, should I report (where ?) things that make puppet return ruby
errors so they can be 'rescued' and have a more meaningful error
message given? I'm happy to file bug report if there is an intention
to fix things like this.
Russell
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
Fwd: Re: [Puppet Users] Using custom facts in Puppet
May I please ask again for some assistance with the question below? I
hope somebody can help me.
Thanks,
Ed Greenberg
Original Message
Subject:Re: [Puppet Users] Using custom facts in Puppet
Date: Tue, 16 Nov 2010 13:14:06 -0600
From: Ed Greenberg
Reply-To: puppet-users@googlegroups.com
To: puppet-users@googlegroups.com
On 11/16/2010 09:33 AM, JWBoerma wrote:
hello,
I am trying to add a custum fact to my puppet module.
I wrote and tested the facter script and it functions as I want it to.
I've got the same issue, trying to distribute a custom fact. I'd like to
return the version of Plesk Panel running on the client.
So I wrote and tested a little fact:
# cat plesk_version.rb
require 'facter'
Facter.add("plesk_version") do
setcode do
%x{cat /usr/local/psa/version}.chomp
end
end
r...@test10:~/lib/ruby/facter#
facter finds this on the client and it returns what I'm looking for.
I want to put this on the server and distribute it. My puppet clients
and puppetmaster server are 0.25.4.
On the puppetmaster I edited /etc/puppet/puppet.conf:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginpath=$vardir/lib/facter
pluginsync=true
[puppetmasterd]
#templatedir=/var/lib/puppet/templates
factsync=true
factpath=$vardir/facts
and also fileserver.conf:
# cat /etc/puppet/fileserver.conf
[files]
path /var/lib/puppet/files
allow *
[plugins]
path /var/lib/puppet/facts
allow *
I put my fact file (plesk_version.rb) in the /var/lib/puppet/facts
directory. I also put a copy in the /var/lib/puppet/plugins directory.
On my client, I ran the puppetd with this command:
# /usr/sbin/puppetd --no-daemonize --verbose --onetime --pluginsync
I got this:
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to retrieve current state of
resource: Could not retrieve information from source(s)
puppet://xxx.x.net/plugins
notice: /File[/var/lib/puppet/lib/facter]: Dependency
file[/var/lib/puppet/lib] has 1 failures
warning: /File[/var/lib/puppet/lib/facter]: Skipping because of failed
dependencies
This seems to have changed some in 0.25.4, and googleing around has not
helped.
May I have a pointer to the correct process?
Thanks,
Ed Greenberg
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@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] Using custom facts in Puppet
On Nov 18, 2010, at 5:23 PM, Ed Greenberg wrote: > and also fileserver.conf: > # cat /etc/puppet/fileserver.conf > [files] > path /var/lib/puppet/files > allow * > [plugins] > path /var/lib/puppet/facts > allow * > > > > I put my fact file (plesk_version.rb) in the /var/lib/puppet/facts > directory. I also put a copy in the /var/lib/puppet/plugins directory. plugins is a pseudo-path, like modules, so you don't need an explicit fileserver.conf entry for it. You should take that out, and instead make a lib/facter/ directory in one of your modules (I use the one that contains most of the manifest which *uses* the fact provided by the plugin) and drop plesk_version.rb in there. Restart puppetmasterd and you should be good to go. This is the approach described in http://docs.puppetlabs.com/guides/plugins_in_modules.html HTH - Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook - -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] using an array to generate several files to down load via erb
Hi I have a requirement to generate several very similar config files which are just a couple of tokens different and with different names. These are barnyard conf files if anyone is interested and differ only in the interface name which is also part of the file name. I can include [eth1, eth2] in the manifest and I want to get files: barnyard.conf.eth1 . interface eth1 ... barnyard.conf.eth2 . interface eth2 ... I could generate these outside puppet but I am trying to get as much of the setp into puppet as I can. Russell -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] using an array to generate several files to down load via erb
"russell.fulton" writes:
I am going to mostly use this as a soapbox to expound on how I do this sort of
thing, but will answer your questions along the way. I hope you don't mind. :)
> I have a requirement to generate several very similar config files
> which are just a couple of tokens different and with different names.
...so, at this point I am thinking that this is a pretty clear case for
modelling each individual configuration file as a puppet 'define', because you
can have more than one of them, and they are almost-but-not-quite identical.
> These are barnyard conf files if anyone is interested and differ only in the
> interface name which is also part of the file name. I can include [eth1,
> eth2] in the manifest and I want to get files:
So, I would look to something like this:
modules/barnyard/manifests/config.pp
define barnyard::config () {
file { "/path/to/config.${name}":
# ...
content => template('barnyard/config.erb')
}
modules/barnyard/templates/config.erb
[<%= name %>]
# ...
manifests/nodes.pp
node "example.com" {
barnyard::config { ["eth0", "eth1"]: }
# ...or do I want this:
barnyard::config { split($interfaces, ','): }
}
Anyway, the essential point is that when you identify a collection of things
that are similar but not identical, and are all related to a single "product"
you generally want to use a 'define' to model them.
Look to where your software management treats things like objects and
instances in traditional programming, and leverage that to model the data.
Regards,
Daniel
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: puppetrun + per host configuration push
hi Daniel, i got the problem of "Why does Puppet keep trying to start a running service?" The ideal way to check for a service is to use the hasstatus parameter, which calls the init script with the status parameter. This should report back to Puppet whether the service is running or stopped. In some broken scripts, however, the status output will be correct (“Ok” or “not running”), but the exit code of the script will be incorrect. Most commonly, the script will always blindly return 0, no matter what the actual service state is. Puppet only uses the exit code, so interprets this as “the service is stopped”. There are two workarounds, and one fix. If you must deal with the scripts broken behavior as is, you can modify your resource to either use the pattern parameter to look for a particular process name, or the status parameter to use a custom script to check for the service status. The fix is to rewrite the init script to use the proper exit codes. When rewriting them, or submitting bug reports to vendors or upstream, be sure to reference the LSB Init Script Actions standard. This should carry more weight by pointing out an official, published standard they’re failing to meet, rather than trying to explain how their bug is causing problems in Puppet. thanks : Sanjiv Singh(iLabs) Impetus InfoTech. On Nov 17, 7:03 am, Daniel Pittman wrote: > "sanjiv.singh" writes: > > i had configured puppet with LDAP > > i.e. node information for stored in LDAP.. > > [...] > > > $ puppet --class ( triggers all nodes ,which include this > > class). > > > as i know when we use following : > > > $ puppetrun --host > > it will look for node entry in puppet class , not in Ldap.. > > > but ,in my development environment , this functionality criticallly required > > . , i want to trigger only perticuler host through puppetrun. > > > how can I achieve this functionality ? > > You want mcollective, and the puppet plugin for that, which is the best > current mechanism for achieving this. > > Regards, > Daniel > > -- > ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 > ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Problem with service :Resource type....
hi Daniel,
i got the problem of "Why does Puppet keep trying to start a running
service?"
The ideal way to check for a service is to use the hasstatus
parameter, which calls the init script with the status parameter. This
should report back to Puppet whether the service is running or
stopped.
In some broken scripts, however, the status output will be correct
(“Ok” or “not running”), but the exit code of the script will be
incorrect. Most commonly, the script will always blindly return 0, no
matter what the actual service state is. Puppet only uses the exit
code, so interprets this as “the service is stopped”.
There are two workarounds, and one fix. If you must deal with the
scripts broken behavior as is, you can modify your resource to either
use the pattern parameter to look for a particular process name, or
the status parameter to use a custom script to check for the service
status.
The fix is to rewrite the init script to use the proper exit codes.
When rewriting them, or submitting bug reports to vendors or upstream,
be sure to reference the LSB Init Script Actions standard. This should
carry more weight by pointing out an official, published standard
they’re failing to meet, rather than trying to explain how their bug
is causing problems in Puppet.
thanks :
Sanjiv Singh(iLabs)
Impetus InfoTech.
On Nov 12, 4:21 pm, "luke.bigum" wrote:
> Hi Sanjiv,
>
> This *should* not happen. Puppet will not restart a service if it's
> already running properly. I'm going to guess that the problem is
> Puppet does not KNOW that Tomcat is running properly and so thinks it
> needs to restart Tomcat every run.
>
> Does your Tomcat LSB/init script (/etc/init.d/tomcat or wherever it is
> on your distro) support the status command correctly?
>
> If it does, it should return zero if the tomcat service is running. If
> this is the case you can add "hasstatus => true" to your
> Service[Tomcat] declaration like so:
>
> service { "tomcat":
> ensure => running,
> hasstatus => true,
>
> }
>
> Puppet will execute the 'status check' and use it's return value to
> determine if the service is running (zero is running). For example,
> here is mysqld's script:
>
> # /etc/init.d/mysqld status
> mysqld (pid x) is running...
> # echo $?
> 0
> #
>
> The script returns zero as you can see, and Puppet does not restart
> this service every time it runs.
>
> According to the documentation (http://docs.puppetlabs.com/references/
> latest/type.html#service), if you don't specify hasstatus then Puppet
> will try determine the status of the service on it's own, usually by
> checking the process table, so if your tomcat service does not run as
> a process name of 'tomcat' this might cause problems.
>
> One last way is to manually specify a "status => cmd" and write your
> own check to determine if tomcat is running or not, but "hasstatus" is
> the way most people would go I think.
>
> -Luke
>
> On Nov 12, 11:10 am, "sanjiv.singh"
> wrote:
>
> > hi all,
>
> > i m tring to use Service resource type as following...
>
> > service { 'tomcat':
> > ensure => running,
>
> > }
>
> > as I know , It will first stop tomcat , then start tomcat..
>
> > but my requirement is like that i do not want to restart it ..
>
> > , i want that if tomcat is allready running , then there is no need to
> > do anything.
> > and if stoped then , start it
>
> > Can anybody tell how can I get this functionality ?
>
> > Guide me if I had any missconception...
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Managing a "complex" directory structure
Hi Lars,
Take a look at virtual resources:
http://projects.puppetlabs.com/projects/1/wiki/Virtual_Resources
-Josh
On Nov 18, 2010, at 3:28 PM, Lars Francke wrote:
> Hi,
>
> I'm trying to manage our Hadoop cluster with Puppet but there are a
> few challenges. The one I'm facing now is managing the following.
>
> I've got an array variable depending on the type of server:
> $hadoop_disks = ['/mnt/disk1', '/mnt/disk2', ...]
>
> Depending on the classes I include for each role there needs to be a
> different directory structure on all those disks.
>
> Namenode + Datanode = /mnt/diskX/hadoop/dfs
> Jobtracker + Tasktracker = /mnt/diskX/hadoop/mapred
>
> Each directory (/hadoop, /hadoop/dfs, /hadoop/mapred) has different
> permissions and both roles can be on the same server (Namenode +
> Datanode).
>
> I've tried multiple different things but I wasn't able to find a
> solution that works. This is what I thought about doing:
>
> base class:
>
> define hadoop_main_directory() {
> file { "${name}/hadoop":
>ensure => directory,
>owner => "root",
>group => "hadoop",
> }
> }
>
> define hadoop_sub_directory($path, $user) {
> file { "${name}/hadoop/${path}":
>ensure => directory,
>owner => $user,
>group => "hadoop",
>require => Hadoop_main_directory[$name],
> }
> }
>
> And in each of the four classes a definition like
>
> hadoop_sub_directory { $hadoop_disks:
> path=> "dfs",
> owner => "hdfs",
> }
>
> But I guess that doesn't work because a resource may be managed multiple
> times.
>
> Any ideas how to solve this? I can provide more details. Our
> configuration is also on github[1] but it's not working right now and
> probably not very pretty. First time I've used Puppet and learning on
> the go...
>
> Cheers,
> Lars
>
> [1] https://github.com/lfrancke/gbif-puppet
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
