I kept getting the hostname not match error:-
err: Could not retrieve catalog from remote server: hostname not match
with the server certificate
I found lots of references which suggested the problem could be to do
with the mismatch of hostnames, because the puppet master and puppet
client are on
I am getting a error and do not understand why it is failing. There
output is below
puppet apply /etc/puppetlabs/puppet/modules/authconfig/tests/init.pp -
vv --noop --debug
info: Loading facts in iptables
info: Loading facts in serve
info: Loading facts in serve
info: Loading facts in iptables
Hi all!
After installing and configuring puppet-dashboard-1.2.1-0.1rc1.el6.noarch.rpm
following the installation instruction given in the "Pro Puppet" book,
everything seems fine. (No errors during installation and configuration.)
However Dashboard only shows me that there are 'x pending tasks'
On Sep 12, 2011, at 9:48 AM, Bernd Adamowicz wrote:
> Hi all!
>
> After installing and configuring puppet-dashboard-1.2.1-0.1rc1.el6.noarch.rpm
> following the installation instruction given in the "Pro Puppet" book,
> everything seems fine. (No errors during installation and configuration.)
install.rb now provides a more helpful error message when the
win32-dir gem is missing (#9174). The sys-admin, win32-process,
win32-dir, and win32-service gems are required to run Puppet on
Windows, and win32-dir is required for install.rb. This was merged
into the 2.7.x branch.
MSI "packages" c
package { "samba" <- there needs to be a colon there. Also, the ensure =>
present should have a comma, not a semicolon, since you have more
parameters. Also, the authconfig exec has two command params and is missing
a comma after the path param, and you are missing a closing double quote for
the ne
On Fri, Sep 9, 2011 at 5:50 PM, R.I.Pienaar wrote:
>
>
> - Original Message -
>> On Fri, Sep 9, 2011 at 5:18 PM, Eric Shamow
>> wrote:
>> > Notify is a resource, notice() is a function. So notice() is
>> > evaluated on the server, whereas notify{} is evaluated on the
>> > client.
>> >
>>
>>> I'm launching puppet with 'service puppet restart'.
Do you get any different results if you run it like:
puppet agent -t
Instead of using that service?
Are you absolutely certain there isn't a stray ruby process running
your old 0.25 puppet agent?
> Well, I can't seem to work out what's go
On Mon, Sep 12, 2011 at 10:50 AM, Ken Barber wrote:
I'm launching puppet with 'service puppet restart'.
>
> Do you get any different results if you run it like:
>
> puppet agent -t
warning: You have configuration parameter $localconfig specified in
[puppetd], which is a deprecated section. I
> On Client:
> service puppet stop
> yum clean all
> rpm --erase puppet
> rpm --erase facter
> rm -fR /var/lib/puppet
> yum upgrade puppet
>
> On server:
> puppetca --clean hproxy11.h.foo.com
>
> On Client:
> service puppet start
Where are the RPM's from that you are using for both 0.25.5 and 2.7.
There is a puppet-dashboard-workers init script that will run a daemon
for you in the background to do this.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from
On Mon, Sep 12, 2011 at 11:24 AM, Ken Barber wrote:
>> On Client:
>> service puppet stop
>> yum clean all
>> rpm --erase puppet
>> rpm --erase facter
>> rm -fR /var/lib/puppet
>> yum upgrade puppet
>>
>> On server:
>> puppetca --clean hproxy11.h.foo.com
>>
>> On Client:
>> service puppet start
>
>
>> Where are the RPM's from that you are using for both 0.25.5 and 2.7.3?
>> I wonder if this can be replicated elsewhere ... what OS distribution
>> and version are you using?
If you can let me know this info I can probably try to replicate.
One thing was troubling me ... and its probably a long
On Mon, Sep 12, 2011 at 12:35 PM, Ken Barber wrote:
>>> Where are the RPM's from that you are using for both 0.25.5 and 2.7.3?
>>> I wonder if this can be replicated elsewhere ... what OS distribution
>>> and version are you using?
>
> If you can let me know this info I can probably try to replica
On Sep 12, 2011, at 11:42 AM, Michael Stahnke wrote:
> There is a puppet-dashboard-workers init script that will run a daemon
> for you in the background to do this.
I presume you are referring to my script and yes, I am aware that there is a
script to run the daemon. My cron script also ex
> The RPM for the puppet client came from the Puppet Labs website. I
> downloaded the source for 2.7.3, and had to make a few changes to the
> SPEC file
(I keep asking this but ...) What OS are you running and version?
Where did you get the RPM's for 0.25?
Also ... why don't you try these RPM's f
On Mon, Sep 12, 2011 at 1:08 PM, Ken Barber wrote:
>> The RPM for the puppet client came from the Puppet Labs website. I
>> downloaded the source for 2.7.3, and had to make a few changes to the
>> SPEC file
>
> (I keep asking this but ...) What OS are you running and version?
> Where did you get t
On Sat, Sep 10, 2011 at 7:59 PM, Jon Forrest wrote:
> On 9/10/2011 6:57 PM, Jonathan Stanton wrote:
>
>>
>> Maybe I'm missing something here, but I think Jon was asking
>> something a bit different -- he doesn't want to check the validity of
>> the erb template (i.e. ruby syntax check) but syntax
On Mon, Sep 12, 2011 at 1:17 PM, Douglas Garstang
wrote:
> On Mon, Sep 12, 2011 at 1:08 PM, Ken Barber wrote:
>>> The RPM for the puppet client came from the Puppet Labs website. I
>>> downloaded the source for 2.7.3, and had to make a few changes to the
>>> SPEC file
>>
>> (I keep asking this bu
You haven't imported the public key for that repository. Ken was probably
assuming that you'd add the repo to your list of repositories and use yum to
install. If you aren't going to do that, you need the GPG key:
RPM-GPG-KEY-puppetlabs (http://yum.puppetlabs.com/RPM-GPG-KEY-puppetlabs)
-Eric
On Mon, Sep 12, 2011 at 1:28 PM, Eric Shamow wrote:
> You haven't imported the public key for that repository. Ken was probably
> assuming that you'd add the repo to your list of repositories and use yum to
> install. If you aren't going to do that, you need the GPG key:
>
> RPM-GPG-KEY-puppetla
We are moving to have our nagios servers generate their nagios configs based
on what services are installed on specific hosts (as well as the hosts
registering themselves). What we have found is that our runtimes have gone
through the roof on this and I'm trying to figure out why (summary below
fr
Hi,
On 11-09-12 04:43 PM, Justin Lambert wrote:
> We are moving to have our nagios servers generate their nagios configs
> based on what services are installed on specific hosts (as well as the
> hosts registering themselves). What we have found is that our runtimes
> have gone through the roof o
I've had a vision of having packages for Puppet, Dashboard,
mcollective, facter, et al, available in native packaging formats for
as many distributions as possible.
I've updated http://yum.puppetlabs.com quite a bit today.
We have most of what I laid out in ticket
http://projects.puppetlabs.com/
Thanks for the response. We're using Posrgres, and the catalog build seems
a bit slow, but nothing compared to the client runtime which is where I've
been focusing. Your assessment is correct, it is just the nagios server
that is extremely slow (~20 mins), there is minimal/no impact to the client
On Mon, Sep 12, 2011 at 2:36 PM, Michael Stahnke wrote:
> I've had a vision of having packages for Puppet, Dashboard,
> mcollective, facter, et al, available in native packaging formats for
> as many distributions as possible.
>
We should try to promote this to the Debian Puppet group, not all of
On Mon, Sep 12, 2011 at 1:41 PM, Douglas Garstang
wrote:
> On Mon, Sep 12, 2011 at 1:28 PM, Eric Shamow wrote:
>> You haven't imported the public key for that repository. Ken was probably
>> assuming that you'd add the repo to your list of repositories and use yum to
>> install. If you aren't g
On Mon, Sep 12, 2011 at 2:36 PM, Michael Stahnke wrote:
> I've had a vision of having packages for Puppet, Dashboard,
> mcollective, facter, et al, available in native packaging formats for
> as many distributions as possible.
>
>
> I've updated http://yum.puppetlabs.com quite a bit today.
>
> We
Douglas,
This is a long shot, but if you have your locate database being updated
nightly, as is the default for RH-based OSes, can you run "locate puppet |
pbcopy" and paste the results into a pastebin/pastie/your paste of choice?
I'd like to see where this shows up on your system. I think ther
Are there any plans to get the latest puppet and facter into
apt.puppetlabs.com?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/nQN-21OcWSYJ.
To post
On Mon, Sep 12, 2011 at 3:28 PM, Eric Shamow wrote:
> Douglas,
>
> This is a long shot, but if you have your locate database being updated
> nightly, as is the default for RH-based OSes, can you run "locate puppet |
> pbcopy" and paste the results into a pastebin/pastie/your paste of choice?
I
All,
I've added Facter nightly builds to our Continuous Integration System.
This means that when new code is pushed to facter, we should have a
build ready to test before too long.
We are currently building against master and the 1.6.x branch. I may
add 1.6rc branch still.
http://downloads.pup
> Michael Stahnke writes:
> I've updated RPMs for el5, el6, f14, f15. Next I'll do el4 and then SLES.
This is great, Michael, thank you very much!
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to
On 11-09-12 05:41 PM, Justin Lambert wrote:
> Thanks for the response. We're using Posrgres, and the catalog build
> seems a bit slow, but nothing compared to the client runtime which is
> where I've been focusing. Your assessment is correct, it is just the
> nagios server that is extremely slow
Brad.
Using the virtual::createsysuser worked.
Thanks again,
Paul
On Wed, Sep 7, 2011 at 1:11 PM, Brad Krane wrote:
> Paul,
>
> I'm not exactly sure, but from your class setup it looks like the
> createsysuser resource would have the full scope of
> accounts::virtual::createsysuser and should
* denmat [2011-09-12]:
> The issue here is that class roles::prod_webserver doesn't expect to
> be passed any values, but there is a bunch of ymllookups that pull
> values in from local yaml files. This causes errors when it complains
> about either invalid parameter (which it is in the above examp
>
> > We're at about the 100 hosts, but have closer to 1500 services - maybe
> > we have exceeded what storeconfigs can do then.
>
> hmm.. so yeah, you've hit the same kind of very bad scaling from the
> nagios config native resources than I've experienced. Seeing how bad it
> becomes with that num
On Tue, Sep 13, 2011 at 12:41 AM, Justin Lambert
wrote:
> Thanks for the response. We're using Posrgres, and the catalog build seems
> a bit slow, but nothing compared to the client runtime which is where I've
> been focusing. Your assessment is correct, it is just the nagios server
> that is ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> We're at about the 100 hosts, but have closer to 1500 services - maybe we
> have exceeded what storeconfigs can do then. If that is the case, is there
> a recommended alternative that isn't manually maintaining config files?
Just to be clear: Afte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The good thing with this method is that you can manage the module
> directory (where the different config file excerpts are stored) with
> 'purge => true' so that only exported resources are present in the final
> nagios configuration (something that
40 matches
Mail list logo
