[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 10:04 PM, Douglas Garstang
wrote:
> On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang
> wrote:
>> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
>> wrote:
>>> I have this:
>>>
>>> class foo::foobar ($version) {
>>> }
>>>
>>> which is called like this:
>>>
>>> class facility::sanjose inherits facility::common {
>>> class { foo::foobar: version => "1.3.13" }
>>> }
>>>
>>> puppet complains with this on the client:
>>> Could not retrieve catalog from remote server: Error 400 on SERVER:
>>> Could not find parent resource type 'facility::sanjose' of type
>>> hostclass in production at
>>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
>>> slog01.pax.xxx.com
>>>
>>> and this on the server:
>>> Syntax error at 'foo::foobar'; expected '}' at
>>> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node
>>> slog01.pax.xxx.com
>>>
>>> I suspect that it doesn't like the '::', but I can't test it without
>>> that because removing the module qualifier and the '::' means the
>>> autoloading doesn't work. So... what's the deal? Can't we use class
>>> names qualified with the module name anymore? I tried putting the
>>> class and module name in single and double quotes too:
>>>
>>> class { "foo::foobar": version => "1.3.13" }
>>> class { 'foo::foobar': version => "1.3.13" }
>>>
>>> same error.
>>>
>>> Doug.
>>>
>>
>> Egads. Why is this so hard?
>>
>> So, I went back and tried it again without the module qualification. I
>> created a module called foo, and put the following into site.pp:
>>
>> import "foo"
>>
>> My modules/foo/manifests/init.pp has this:
>>
>> class foobar ($version) {
>> }
>>
>> Now, when I use 'include foobar' everyone is happy. However, when I do
>> "class { foobar: version => "1.3.13" }", puppet complains. It doesn't
>> like the way I'm calling the class. It reports the error:
>>
>> debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw
>> yaml; using pson
>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'
>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'
>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
>> /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'
>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in
>> `retrieve_new_catalog'
>> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'
>> /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
>> /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
>> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'
>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in
>> `retrieve_new_catalog'
>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'
>> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
>> /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'
>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
>> `call'
>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
>> `__signal__'
>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
>> `each'
>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
>> `__signal__'
>> (eval):2:in `signal'
>> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in
>> `sound_alarm'
>> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'
>> /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'
>> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
>> /usr/sbin/puppetd:4
>> err: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Could not find parent resource type 'facility::sanjose' of
>> type hostclass in production at
>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
>> slog01.pax.xxx.com
>>
>> The module facility::sanjose is the calling class. So, what am I doing
>> wrong? I'm just following the examples in the release notes.
>>
>> Doug.
>>
>
> Well, here's some more data. The call to "class { foobar: ver =>
> "1.3.13" }"
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang
wrote:
> On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
> wrote:
>> I have this:
>>
>> class foo::foobar ($version) {
>> }
>>
>> which is called like this:
>>
>> class facility::sanjose inherits facility::common {
>> class { foo::foobar: version => "1.3.13" }
>> }
>>
>> puppet complains with this on the client:
>> Could not retrieve catalog from remote server: Error 400 on SERVER:
>> Could not find parent resource type 'facility::sanjose' of type
>> hostclass in production at
>> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
>> slog01.pax.xxx.com
>>
>> and this on the server:
>> Syntax error at 'foo::foobar'; expected '}' at
>> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node
>> slog01.pax.xxx.com
>>
>> I suspect that it doesn't like the '::', but I can't test it without
>> that because removing the module qualifier and the '::' means the
>> autoloading doesn't work. So... what's the deal? Can't we use class
>> names qualified with the module name anymore? I tried putting the
>> class and module name in single and double quotes too:
>>
>> class { "foo::foobar": version => "1.3.13" }
>> class { 'foo::foobar': version => "1.3.13" }
>>
>> same error.
>>
>> Doug.
>>
>
> Egads. Why is this so hard?
>
> So, I went back and tried it again without the module qualification. I
> created a module called foo, and put the following into site.pp:
>
> import "foo"
>
> My modules/foo/manifests/init.pp has this:
>
> class foobar ($version) {
> }
>
> Now, when I use 'include foobar' everyone is happy. However, when I do
> "class { foobar: version => "1.3.13" }", puppet complains. It doesn't
> like the way I'm calling the class. It reports the error:
>
> debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw
> yaml; using pson
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'
> /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
> /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
> /usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'
> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
> `call'
> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
> `__signal__'
> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
> `each'
> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
> `__signal__'
> (eval):2:in `signal'
> /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in
> `sound_alarm'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'
> /usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'
> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'
> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
> /usr/sbin/puppetd:4
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find parent resource type 'facility::sanjose' of
> type hostclass in production at
> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
> slog01.pax.xxx.com
>
> The module facility::sanjose is the calling class. So, what am I doing
> wrong? I'm just following the examples in the release notes.
>
> Doug.
>
Well, here's some more data. The call to "class { foobar: ver =>
"1.3.13" }" works fine when I remove it from the class it was in, and
put it in a node definition. I'd ask if parameterized classes could
only be called in nodes, except that the example in the rele
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
wrote:
> I have this:
>
> class foo::foobar ($version) {
> }
>
> which is called like this:
>
> class facility::sanjose inherits facility::common {
> class { foo::foobar: version => "1.3.13" }
> }
>
> puppet complains with this on the client:
> Could not retrieve catalog from remote server: Error 400 on SERVER:
> Could not find parent resource type 'facility::sanjose' of type
> hostclass in production at
> /etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
> slog01.pax.xxx.com
>
> and this on the server:
> Syntax error at 'foo::foobar'; expected '}' at
> /etc/puppet/modules/facility/manifests/sanjose.pp:32 on node
> slog01.pax.xxx.com
>
> I suspect that it doesn't like the '::', but I can't test it without
> that because removing the module qualifier and the '::' means the
> autoloading doesn't work. So... what's the deal? Can't we use class
> names qualified with the module name anymore? I tried putting the
> class and module name in single and double quotes too:
>
> class { "foo::foobar": version => "1.3.13" }
> class { 'foo::foobar': version => "1.3.13" }
>
> same error.
>
> Doug.
>
Egads. Why is this so hard?
So, I went back and tried it again without the module qualification. I
created a module called foo, and put the following into site.pp:
import "foo"
My modules/foo/manifests/init.pp has this:
class foobar ($version) {
}
Now, when I use 'include foobar' everyone is happy. However, when I do
"class { foobar: version => "1.3.13" }", puppet complains. It doesn't
like the way I'm calling the class. It reports the error:
debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw
yaml; using pson
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:71:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:193:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:50:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:225:in `retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/1.8/benchmark.rb:307:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:224:in `retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:102:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:143:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:101:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:76:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
`call'
/usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
`__signal__'
/usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
`each'
/usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:95:in
`__signal__'
(eval):2:in `signal'
/usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:313:in
`sound_alarm'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:80:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/daemon.rb:124:in `start'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:132:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:89:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:398:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:301:in `run'
/usr/sbin/puppetd:4
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find parent resource type 'facility::sanjose' of
type hostclass in production at
/etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
slog01.pax.xxx.com
The module facility::sanjose is the calling class. So, what am I doing
wrong? I'm just following the examples in the release notes.
Doug.
--
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] File /etc/yum.conf does not contain a main section
On Wed, Jul 21, 2010 at 9:34 PM, James Turnbull wrote: > Douglas Garstang wrote: >> I just upgraded puppet from 0.25.5 to 0.26, and I'm getting this: >> >> (/Stage[main]/Repo::Livegamer_software_base/Yumrepo[Livegamer-Software-Base]) >> Could not evaluate: File /etc/yum.conf does not contain a main section > > Well I'd say that'd be a bug. > > Can you please log a ticket with the results of the master and agent > runs with --trace --debug --verbose enabled? James, Probably a minor bug. I retyped the [main] line, and puppet was happy. There was probably a trailing tab or white space at the end of the line. Easy to reproduce I guess still a bug? Doug. -- 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] File /etc/yum.conf does not contain a main section
Douglas Garstang wrote: > I just upgraded puppet from 0.25.5 to 0.26, and I'm getting this: > > (/Stage[main]/Repo::Livegamer_software_base/Yumrepo[Livegamer-Software-Base]) > Could not evaluate: File /etc/yum.conf does not contain a main section Well I'd say that'd be a bug. Can you please log a ticket with the results of the master and agent runs with --trace --debug --verbose enabled? Thanks James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- 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] First Foray into Parameterized Classes.... not so good
I have this:
class foo::foobar ($version) {
}
which is called like this:
class facility::sanjose inherits facility::common {
class { foo::foobar: version => "1.3.13" }
}
puppet complains with this on the client:
Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find parent resource type 'facility::sanjose' of type
hostclass in production at
/etc/puppet/modules/facility/manifests/sanjose/logserver.pp:1 on node
slog01.pax.xxx.com
and this on the server:
Syntax error at 'foo::foobar'; expected '}' at
/etc/puppet/modules/facility/manifests/sanjose.pp:32 on node
slog01.pax.xxx.com
I suspect that it doesn't like the '::', but I can't test it without
that because removing the module qualifier and the '::' means the
autoloading doesn't work. So... what's the deal? Can't we use class
names qualified with the module name anymore? I tried putting the
class and module name in single and double quotes too:
class { "foo::foobar": version => "1.3.13" }
class { 'foo::foobar': version => "1.3.13" }
same error.
Doug.
--
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] File /etc/yum.conf does not contain a main section
I just upgraded puppet from 0.25.5 to 0.26, and I'm getting this: (/Stage[main]/Repo::Livegamer_software_base/Yumrepo[Livegamer-Software-Base]) Could not evaluate: File /etc/yum.conf does not contain a main section However, my /etc/yum.conf contains this. What's wrong with that? Is puppet smoking crack? [main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log distroverpkg=redhat-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 # Note: yum-RHN-plugin doesn't honor this. metadata_expire=1h installonly_limit = 5 # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d Doug. -- 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] 0.24.8: puppetd --onetime and schedules?
> And are you using --onetime to trigger these random runs, via cron or > something? > -Alan > We run puppet from cron via wrapper. The wrapper looks for a file that signals "not to run" if we are in a maintenance mode. Cheers, Ryan -- 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] 0.24.8: puppetd --onetime and schedules?
Ryan Dooley wrote:
> Howdy Alan,
>
> On 7/21/2010 6:04 PM, Alan Sparks wrote:
>
>> Is there an issue with --onetime and schedules? Is there something else
>> that needs to be supplied to make --onetime work as expected (aside from
>> --ignoreschedules; I don't want to ignore schedule limitations, I'd like
>> to apply whatever would apply that the schedule would permit).
>>
>
> I pretty much use this setup. My clients run randomly once an hour for
> most operations. Disk intensive operations (package installs) are dealt
> with during the configured schedule. My configuration has something
> that looks like this:
>
> class Foo {
> package {
> bar:
> schedule => daily, ensure => present;
> }
> }
>
> any operation that I want to restrict includes the schedule.
>
> Cheers,
> Ryan
>
And are you using --onetime to trigger these random runs, via cron or
something?
-Alan
--
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] 2.6, parameterized classes, external nodes
Patrick Mohr wrote:
> On Jul 21, 2010, at 5:44 PM, Alan Sparks wrote:
>
>
>> Many of us have the problem of needing to simulate the instantiation of
>> definitions via external nodes (e.g., the multiple Apache vhosts
>> situation, or multiple service instantiations with unique
>> configurations). Since these are singletons, I'm guessing parameterized
>> classes won't help in solving this problem... Does 2.6 provide any new
>> support toward solving it?
>>
>
> Now I'm confused. Isn't a parameterized class the same as a define except
> for the class being a singleton?
>
>
So what does that mean exactly? Can you do:
class { myclass: name => "foo", myval => "one" }
class { myclass: name => "baz", myval => "two" }
And instantiate a set of unique resources?
-Alan
--
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] 2.6, parameterized classes, external nodes
On Jul 21, 2010, at 5:44 PM, Alan Sparks wrote: > Many of us have the problem of needing to simulate the instantiation of > definitions via external nodes (e.g., the multiple Apache vhosts > situation, or multiple service instantiations with unique > configurations). Since these are singletons, I'm guessing parameterized > classes won't help in solving this problem... Does 2.6 provide any new > support toward solving it? Now I'm confused. Isn't a parameterized class the same as a define except for the class being a singleton? -- 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] Installing a module FIRST
On Jul 21, 2010, at 5:16 PM, Douglas Garstang wrote: > On Wed, Jul 21, 2010 at 4:44 PM, Patrick Mohr wrote: >> >> On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote: >> >>> Anyone, >>> >>> How can I guarantee that all components of the LDAP client module get >>> installed before ANY components of any other module? >> >> Use 2.6.x and use run stages. >> >> -OR- >> >> Use 0.25.x and make all User and Package resources depend on that class. > > Doing that is a sure fire path to cyclic dependency hell. > I'll grant you that. I did it for that package setup, but it was very annoying. -- 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] Installing a module FIRST
Ryan Y. Coleman wrote: > I spent a few minutes playing with stages as well and they seem like > a great solution to certain problems. Will there be more > documentation made available about how to use stages after final > release? All I'm familiar with is what's in the changelog. > We've had final release. :) We don't currently have any additional documentation but I'll have a chat with Jeff, Dan et al about some additional notes. Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- 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] 0.24.8: puppetd --onetime and schedules?
Howdy Alan,
On 7/21/2010 6:04 PM, Alan Sparks wrote:
> I have a custom schedule to apply changes to various classes (e.g.,
> "File { schedule => normal }"). This works fine for puppetd running as
> a daemon. However, I note that if I run puppetd with the --onetime
> option, it applies none of my actions. puppetd --test will apply them,
> and the normal puppetd run by the daemon will as well (just a few
> minutes later).
>
> Is there an issue with --onetime and schedules? Is there something else
> that needs to be supplied to make --onetime work as expected (aside from
> --ignoreschedules; I don't want to ignore schedule limitations, I'd like
> to apply whatever would apply that the schedule would permit).
>
> If I can provide more details, please let me know.
> -Alan
I pretty much use this setup. My clients run randomly once an hour for
most operations. Disk intensive operations (package installs) are dealt
with during the configured schedule. My configuration has something
that looks like this:
class Foo {
package {
bar:
schedule => daily, ensure => present;
}
}
any operation that I want to restrict includes the schedule.
Cheers,
Ryan
--
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] 0.24.8: puppetd --onetime and schedules?
I have a custom schedule to apply changes to various classes (e.g.,
"File { schedule => normal }"). This works fine for puppetd running as
a daemon. However, I note that if I run puppetd with the --onetime
option, it applies none of my actions. puppetd --test will apply them,
and the normal puppetd run by the daemon will as well (just a few
minutes later).
Is there an issue with --onetime and schedules? Is there something else
that needs to be supplied to make --onetime work as expected (aside from
--ignoreschedules; I don't want to ignore schedule limitations, I'd like
to apply whatever would apply that the schedule would permit).
If I can provide more details, please let me know.
-Alan
--
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] 2.6, parameterized classes, external nodes
The release notes do not mention whether the external node classifier system now supports parameterized classes, and if so, what the syntax expected would be to use it. Is this supported? Also, the release notes indicate with respect to parameterized classes: "with the significant difference that definitions have multiple instances whilst classes remain singletons." Many of us have the problem of needing to simulate the instantiation of definitions via external nodes (e.g., the multiple Apache vhosts situation, or multiple service instantiations with unique configurations). Since these are singletons, I'm guessing parameterized classes won't help in solving this problem... Does 2.6 provide any new support toward solving it? Thanks. -Alan -- 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] Installing a module FIRST
On Wed, Jul 21, 2010 at 4:44 PM, Patrick Mohr wrote: > > On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote: > >> Anyone, >> >> How can I guarantee that all components of the LDAP client module get >> installed before ANY components of any other module? > > Use 2.6.x and use run stages. > > -OR- > > Use 0.25.x and make all User and Package resources depend on that class. Doing that is a sure fire path to cyclic dependency hell. -- 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] Installing a module FIRST
I spent a few minutes playing with stages as well and they seem like a great
solution to certain problems. Will there be more documentation made available
about how to use stages after final release? All I'm familiar with is what's in
the changelog.
--Ryan
- Original Message -
> From: "Douglas Garstang"
> To: puppet-users@googlegroups.com
> Sent: Wednesday, July 21, 2010 7:47:46 PM
> Subject: Re: [Puppet Users] Installing a module FIRST
> On Wed, Jul 21, 2010 at 4:32 PM, Avi Miller
> wrote:
> > Hey Douglas
> >
> > Douglas Garstang wrote:
> >>
> >> How can I guarantee that all components of the LDAP client module
> >> get
> >> installed before ANY components of any other module?
> >
> > Take a look at the new Run Stages[1] functionality in Puppet 2.6.
> > Run stages
> > would allow you to specify that the LDAP class has to run first
> > before any
> > other module is actioned.
>
> So... the release notes have an example:
>
> class yum { ... }
> class redhat {
> ...
> class { yum: stage => pre }
> }
>
> followed by the statement:
> "Note that we’re using the new parameterized classes here – this is
> necessary because of the class-level limitations of Run Stages. These
> limitations are present because of the complication of trying to
> untangle resource dependencies across stage boundaries if we allowed
> arbitrary resources to specify stages."
>
> Any idea what that means?
>
> Doug.
>
>
> "
>
> --
> 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] Installing a module FIRST
On Wed, Jul 21, 2010 at 4:55 PM, Jeff McCune wrote: > On Wed, Jul 21, 2010 at 4:47 PM, Douglas Garstang >> "Note that we’re using the new parameterized classes here – this is >> necessary because of the class-level limitations of Run Stages. These >> limitations are present because of the complication of trying to >> untangle resource dependencies across stage boundaries if we allowed >> arbitrary resources to specify stages." >> >> Any idea what that means? > > It means the design is to specify the run stage at class "level", not > resource "level". I was kinda wondering why it was a requirement to use parameterized classes. -- 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] Installing a module FIRST
On Wed, Jul 21, 2010 at 4:47 PM, Douglas Garstang > "Note that we’re using the new parameterized classes here – this is > necessary because of the class-level limitations of Run Stages. These > limitations are present because of the complication of trying to > untangle resource dependencies across stage boundaries if we allowed > arbitrary resources to specify stages." > > Any idea what that means? It means the design is to specify the run stage at class "level", not resource "level". -- Jeff McCune 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] Installing a module FIRST
On Wed, Jul 21, 2010 at 4:32 PM, Avi Miller wrote:
> Hey Douglas
>
> Douglas Garstang wrote:
>>
>> How can I guarantee that all components of the LDAP client module get
>> installed before ANY components of any other module?
>
> Take a look at the new Run Stages[1] functionality in Puppet 2.6. Run stages
> would allow you to specify that the LDAP class has to run first before any
> other module is actioned.
So... the release notes have an example:
class yum { ... }
class redhat {
...
class { yum: stage => pre }
}
followed by the statement:
"Note that we’re using the new parameterized classes here – this is
necessary because of the class-level limitations of Run Stages. These
limitations are present because of the complication of trying to
untangle resource dependencies across stage boundaries if we allowed
arbitrary resources to specify stages."
Any idea what that means?
Doug.
"
--
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] Installing a module FIRST
On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote: > Anyone, > > How can I guarantee that all components of the LDAP client module get > installed before ANY components of any other module? Use 2.6.x and use run stages. -OR- Use 0.25.x and make all User and Package resources depend on that class. > This is another one of those situations where the ability to have > modules fully installed in order they are listed would be hugely > beneficial. Making everything install in the order it's listed means you can't explicitly specify dependencies. Explicit dependencies are one of the reasons I really like using puppet over shell scripts. -- 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] Installing a module FIRST
Hey Douglas Douglas Garstang wrote: How can I guarantee that all components of the LDAP client module get installed before ANY components of any other module? Take a look at the new Run Stages[1] functionality in Puppet 2.6. Run stages would allow you to specify that the LDAP class has to run first before any other module is actioned. cYa, Avi [1] http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#Run+Stages -- 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] Installing a module FIRST
Anyone, How can I guarantee that all components of the LDAP client module get installed before ANY components of any other module? The need for this is driven from the fact that various packages will often install a local user. In order to make sure that that id's of any of these local users do not clash with id's from LDAP users, the ldap client configuration needs to be fully deployed first. When the RPM adds the user as part of it's pre/post install script, and useradd calls getpwent, since ldap is already up, the same user id will not get re-used. This is another one of those situations where the ability to have modules fully installed in order they are listed would be hugely beneficial. Doug. -- 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] Monit module that supports both monitrc and monit.conf
Does anyone know of or have a module ( they are willing to share ) that supports both monitrc and monit.conf. Thank in advance. -- 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] Failing to install Packages
On Tue, Jul 20, 2010 at 11:13 AM, Todd Zullinger wrote:
> Douglas Garstang wrote:
>> After going through some dependency hell trying to get the
>> rpmforge-release package installed before the RPMforge repo, which
>> contains the GPG key for RPMforge packages, now I find that when
>> puppet tries to install this package, this happens:
>>
>> Jul 20 10:20:04 slog01 puppetd[2753]:
>> (//yum::client/Package[rpmforge-release]/ensure) change from absent to
>> present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install
>> rpmforge-release' returned 1: warning: rpmts_HdrFromFdno: Header V3
>> DSA signature: NOKEY, key ID 6b8d79e6
>>
>> The package actually installs, but since it's flagging a warning, and
>> it's exit code is 1, AND just about everything else relies on this
>> repository being there, puppet fails everything else after it. It
>> would be really nice if puppet could ignore the warnings. Now I need
>> to find a way to install this rpm outside of puppet, probably in the
>> %post section of the kickstart.
>
> You may need to install the gpg key for the the rpmfoge-release
> package first. That might be something like:
>
> exec { 'install-rpmforge-gpg-key':
> # http URL's work too, but would't be as secure as veryfying the key first.
> command => 'rpm --import /path/to/rpmforge-key',
> unless => 'rpm -q --quiet gpg-pubkey-6b8d79e6',
> }
>
> package { 'rpmforge-release':
> ensure => installed,
> require => Exec['install-rpmforge-gpg-key'],
> }
Yeah, but you gotta get the RPM onto the system first. This turned out
to be user error. It was failing because the gpgcheck was set to 1 on
the repo, and the key hadn't been installed yet. I ended up giving up
on it with puppet. The %post section of the kickstart install installs
the rpmforg-release and epel-release packages, which contain the keys.
When the system comes up, gpgcheck=1, and everyone is happy.
Doug
--
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: Massaging Puppet around parallel ruby installs hackery on CentOS 5.5
On Jul 20, 4:25 pm, Eric Sorenson wrote:
> On Jul 20, 2010, at 4:19 PM, Ramin K wrote:
>
> > My question is there a way to have Puppet gem install into 1.8.7 while
> > running on top 1.8.5? I'm testing with package { "mysql": provider =>
> > gem, ensure => "2.7", } and getting the error " Could not match ruby
> > 1.8.5 (2006-08-25) [x86_64-linux] Jul 20 15:59:02 webapp01
> > puppetd[4451]: (//application_rubygems/Package[mysql]) Failed to
> > retrieve current state of resource: Provider gem is not functional on
> > this platform"
>
> These are determined at runtime by the PATH environment variable inherited by
> the puppetd process, so if you manipulate the path in you startup scripts to
> put /usr/local/bin/ first, this should work.
>
Thanks, you got me pointed in the right direction. This ticket
http://projects.reductivelabs.com/issues/1893 makes me think that you
need to specify any additions to your path in the puppet.conf. I tried
mucking with PATH variables in other places, but Puppet never picked
up the additions.
Ramin K
--
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: Installping puppet with kickstart -- Cannot find local fact /proc/cpuinfo
On Jul 21, 2010, at 4:47 AM, Harihara Vinayakaram wrote:
> I found this reply from one of the users in the same thread . The
> solution was to
> 1) Copy the existing /etc/rc.local to /etc/rc.local.orig
> 2) Replace the /etc/rc.local with a script that run puppetd , moves /
> etc/rc.local.orig to /etc/rc.local , reboot
>
Just some things to keep in mind:
*) If puppet hangs in rc.local, the startup process will hang in some distros.
*) If puppet's not daemonized, and puppet returns an error, rc.local will stop
executing in some distros.
*) Make sure that nothing changes rc.local back until puppet successfully
finishes the first run.
>
> On Jul 20, 10:28 pm, Patrick Mohr wrote:
>> On Tue, Jul 20, 2010 at 5:23 AM, Tore wrote:
>>> We use Satellite to kickstart our nodes. Have you tried to do this
>>> after %post?
>>
>>> kickstart-file, I've removed a few lines:
>>
>>> install
>>> text
>>> []
>>> %packages
>>> @ Base
>>
>>> %pre
>>> $kickstart_start
>>> $SNIPPET('pre_install_network_config')
>>
>>> %post --nochroot
>>> mkdir /mnt/sysimage/tmp/ks-tree-copy
>>> [...]
>>> cp `awk '{ if ($1 ~ /%include/) {print $2}}' /tmp/ks.cfg` /tmp/ks.cfg /
>>> mnt/sysimage/root
>>
>>> %post
>>> ( # Log %post errors
>>> # --Begin RHN Satellite command section--
>>> [...]
>>> # --End RHN Satellite command section--
>>
>>> [...]
>>> ) >> /root/ks-post.log 2>&1
>>> $SNIPPET('post_install_network_config')
>>
>>> $SNIPPET('spacewalk/1/install_and_config_puppet')
>>
>>> $SNIPPET('post_install_kernel_options')
>>> $SNIPPET('koan_environment')
>>> $kickstart_done
>>
>>> I have no idea if that will work for you, its strange that /proc/
>>> cpuinfo isn't available since I assume anaconda uses that information
>>> during installation.
>>
>> I don't remember much about the redhat install process, but are you
>> chrooting before you run puppet? If so, the probably is probably that /proc
>> is not mounted inside of the chroot environment?
>>
>> On 16 Jul, 13:39, Harihara Vinayakaram wrote:
>>
Hi
I have been trying to get puppet working with kickstart. I am
trying to install Hadoop on the nodes. Installing puppet from
kickstart work and when the machine restarts, certificates are pulled
down and hadoop user is created and files are extracted.
>>
I want all the user creation etc to be done before the machine
reboots so that I can set up init.d scripts to do a start of hadoop .
So I run the puppetd --server ... --one-time --no-daemonize as part
of the late_command with a chroot /target .
>>
But this fails saying cannot find local fact /proc/cpuinfo . I
tried to a mount /proc in the script but the machine hangs. Is this a
known problem
>>
http://groups.google.com/group/puppet-users/browse_thread/thread/b2e3...
has a solution but it does not work . The only difference I can see is
that it runs the puppetd as -in-target instead of a chroot . Any ideas
will be helpful
>>
>>> --
>>> 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.
>
--
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: Installping puppet with kickstart -- Cannot find local fact /proc/cpuinfo
I found this reply from one of the users in the same thread . The
solution was to
1) Copy the existing /etc/rc.local to /etc/rc.local.orig
2) Replace the /etc/rc.local with a script that run puppetd , moves /
etc/rc.local.orig to /etc/rc.local , reboot
Regards
Hari
On Jul 20, 10:28 pm, Patrick Mohr wrote:
> On Tue, Jul 20, 2010 at 5:23 AM, Tore wrote:
> > We use Satellite to kickstart our nodes. Have you tried to do this
> > after %post?
>
> > kickstart-file, I've removed a few lines:
>
> > install
> > text
> > []
> > %packages
> > @ Base
>
> > %pre
> > $kickstart_start
> > $SNIPPET('pre_install_network_config')
>
> > %post --nochroot
> > mkdir /mnt/sysimage/tmp/ks-tree-copy
> > [...]
> > cp `awk '{ if ($1 ~ /%include/) {print $2}}' /tmp/ks.cfg` /tmp/ks.cfg /
> > mnt/sysimage/root
>
> > %post
> > ( # Log %post errors
> > # --Begin RHN Satellite command section--
> > [...]
> > # --End RHN Satellite command section--
>
> > [...]
> > ) >> /root/ks-post.log 2>&1
> > $SNIPPET('post_install_network_config')
>
> > $SNIPPET('spacewalk/1/install_and_config_puppet')
>
> > $SNIPPET('post_install_kernel_options')
> > $SNIPPET('koan_environment')
> > $kickstart_done
>
> > I have no idea if that will work for you, its strange that /proc/
> > cpuinfo isn't available since I assume anaconda uses that information
> > during installation.
>
> I don't remember much about the redhat install process, but are you
> chrooting before you run puppet? If so, the probably is probably that /proc
> is not mounted inside of the chroot environment?
>
> On 16 Jul, 13:39, Harihara Vinayakaram wrote:
>
> > > Hi
> > > I have been trying to get puppet working with kickstart. I am
> > > trying to install Hadoop on the nodes. Installing puppet from
> > > kickstart work and when the machine restarts, certificates are pulled
> > > down and hadoop user is created and files are extracted.
>
> > > I want all the user creation etc to be done before the machine
> > > reboots so that I can set up init.d scripts to do a start of hadoop .
> > > So I run the puppetd --server ... --one-time --no-daemonize as part
> > > of the late_command with a chroot /target .
>
> > > But this fails saying cannot find local fact /proc/cpuinfo . I
> > > tried to a mount /proc in the script but the machine hangs. Is this a
> > > known problem
>
> > >http://groups.google.com/group/puppet-users/browse_thread/thread/b2e3...
> > > has a solution but it does not work . The only difference I can see is
> > > that it runs the puppetd as -in-target instead of a chroot . Any ideas
> > > will be helpful
>
> > --
> > 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.
