[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 kc7...@gmail.com wrote:
On Tue, Jul 20, 2010 at 5:23 AM, Tore tore.lo...@gmail.com 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 21
$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 hvr...@gmail.com 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.compuppet-users%2bunsubscr...@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] 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 kc7...@gmail.com wrote:
On Tue, Jul 20, 2010 at 5:23 AM, Tore tore.lo...@gmail.com 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 21
$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 hvr...@gmail.com 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.compuppet-users%2bunsubscr...@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: Massaging Puppet around parallel ruby installs hackery on CentOS 5.5
On Jul 20, 4:25 pm, Eric Sorenson eric.soren...@me.com 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] Failing to install Packages
On Tue, Jul 20, 2010 at 11:13 AM, Todd Zullinger t...@pobox.com 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] 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.
[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.
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.
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
On Wed, Jul 21, 2010 at 4:32 PM, Avi Miller avi.mil...@gmail.com 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 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:55 PM, Jeff McCune j...@puppetlabs.com 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
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 doug.garst...@gmail.com
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 avi.mil...@gmail.com
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:44 PM, Patrick Mohr kc7...@gmail.com 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.
[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.
[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.
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.
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] 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 kc7...@gmail.com 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] 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] 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] 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] 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.
[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.
[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.
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.
Re: [Puppet Users] File /etc/yum.conf does not contain a main section
On Wed, Jul 21, 2010 at 9:34 PM, James Turnbull ja...@puppetlabs.com 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.
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
doug.garst...@gmail.com 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.
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
doug.garst...@gmail.com 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 release notes
is clearly called from within another class.
Doug.
--
You received this message because you are subscribed to
[Puppet Users] Re: First Foray into Parameterized Classes.... not so good
On Wed, Jul 21, 2010 at 10:04 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
On Wed, Jul 21, 2010 at 9:55 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
On Wed, Jul 21, 2010 at 9:24 PM, Douglas Garstang
doug.garst...@gmail.com 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 release notes
is clearly called
