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 fac
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: ver
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:
>
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 mai
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
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 f
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
> 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 t
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 limitatio
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)
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,
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 componen
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 fina
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 m
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 pupp
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
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-
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:
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 complica
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
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
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
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
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 n
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.c
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
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 n
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
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
29 matches
Mail list logo
