Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch

[Russell Van Tassell]

On Tue, May 1, 2012 at 12:45 PM, Romeo Theriault
wrote:

> Unfortunately, solaris
> doesn't have a cron.d directory where we can drop crontab files
> either.
>

Are you talking about /var/spool/cron/crontab on Solaris?  (think that's
the right path)

It won't reload them without being kicked. But, you can play tricks with it
by dropping the file there, then reload it by invoking "crontab" and
feeding it the new file. You might have to massage it to get things to work
properly, but it should be possible (ie. I've done it this way, manually,
in a previous life).

-- 
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 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] slow file transfer using puppet client on solaris

[Russell Van Tassell]

Have you tried other transfers over SSH or similar? I'm guessing this isn't
limited to puppet?

Check the interface settings and make sure the (default) auto-negotiation
worked with your switch... Sun boxes of that age (particularly with hme and
le cards) were notoriously bad in negotiating full duplex 10/100Mb with
Cisco switches. Generally you just have to hard-set the interface and
you're fine after that...

Hope that helps...
RVT

On Fri, Apr 13, 2012 at 7:08 AM, r0k5t4r  wrote:

> Hi,
>
> I just wrote a new module and noticed the the file transfer under
> solaris is extremely slow. The file is just about 50mbyte and it
> transfers ok under Linux but not under Solaris. The Solaris box is
> really old (Ulta10) and is running puppet 2.7.9.
>
> Is this a limitation of the puppet client under Solaris or is it
> because the box is too slow to handle the transfer?
>
> Regards,
> Oliver
>
> --
> 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 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-users@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] puppetd locking up?

[Russell Van Tassell]

On Tue, Apr 10, 2012 at 2:24 PM, David Alden  wrote:

> If I look at what puppet is running:
>
> # ps -elfw | grep 10726
> 5 S root 10726 1  0  81   1 - 61549 poll_s 15:15 ?00:00:17
> /usr/bin/ruby /usr/sbin/puppetd --debug --verbose
> 0 Z root 11429 10726  0  81   1 - 0 exit   15:39 ?00:00:00
> [sh] 
>
>
Any chance you've looked at your log files to see what that last-forked
shell is doing? Seems like a process isn't exiting (maybe doesn't want to
give up a handle) and the puppet client is sitting around waiting for it?

Cheers -
RVT

-- 
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 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] Getting started

[Russell Van Tassell]

It might also be helpful to include your O/S, here ... as there are many
linuxes where installing puppet can largely be reduced to installing the
right RPMs out of one repository or another (so you worry less about
compiling and manufacturing basic configs than just learning how to make
puppet go).



On Thu, Apr 5, 2012 at 1:42 PM, Brown, Rodrick  wrote:

>  I really hate poor documentation. 
>
> ** **
>
> I’m following along in PDF documentation I downloaded from the official
> site and I’m stuck after I installed rack & passenger modules from
> rubygems. 
>
> I ran the passenger build script and it compiled and installed into my
> local apache httpd server successfully. 
>
> ** **
>
> Now where do I find an working example of puppetmaster.conf ? 
>
> Which config.ru should I be coping into
> /usr/share/puppet/rack/puppetmasterd ? 
>
> ** **
>
> Is there a guide on generate the pem files required for use when defining
> the virtual host settings in puppetmaster? 
>
> ** **
>
> I’m almost fed-up already and I’ve not even gotten 1 agent configured to
> talk to my sever  
>
> ** **
>
> Puppet seems way too clumber some with the amount of dependencies required
> so far.  
>
> ** **
>
> I almost feel like going back to hacking on my system based on Python &
> Fabric L
>
> ** **
>
> --RB 
>
> Please visit our website for important disclaimers/disclosures regarding
> Knight’s products and services:
>
> http://knight.com/KnightEmailDisclaimer.html
>
>   --
> 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 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-users@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] onlyif executed out of order

[Russell Van Tassell]

The obfuscation it seems you have done here doesn't make this clear (at
least to me).

It would appear your "only if" is executing, as-directed, to see if it may
execute the exec within the class. (Assuming you have replaced "apprunner"
with "my_user" in places, there)

It might help to de-obfuscate a bit ... or, make it clear where the users
are the same/different before the obfuscated class and the
(non-obfuscated?) log messages.



On Mon, Apr 2, 2012 at 2:17 PM, John Shoemaker
wrote:

> I have a basic setup where I have an Exec that is in a class. The Exec has
> an onlyif that checks for the existence of a file. Despite me indicating
> that the Class requires that File, the onlyif check is executed before the
> File.
>
> Basic example
>
> https://gist.github.com/b1e1741d686881f115c4
>
> It works if I run apply twice (file gets created first time but exec
> doesn't execute, exec gets run the second time)
>
> (I get the same behavior if I manually set up the File -> Exec
> relationship too, so I don't think its related to the Class)
>
> --
> 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/-/osNqluVlG3YJ.
> To post to this group, send email to puppet-users@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-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Use netgroups as classes

[Russell Van Tassell]

It's a bit of a change, but you're probably best just looking at ENCs
(External Node Classifiers)...

http://docs.puppetlabs.com/guides/external_nodes.html

As with anything else, there's a half dozen (if not more) ways to do it.
Some of the "gotchas" include making the ENC a single point of failure. It
is probably best (?) to generate a simple node classification file on the
server, then push that out to the clients. The clients can either pick it
up by a simple YAML file, or through another equally simple script.

Hope that helps get you started in the right direction...





On Mon, Mar 19, 2012 at 1:05 AM, Nikhil Mulley  wrote:

> Hi,
>
> In my puppet configuration, to deploy certain files to group of nodes,
> everytime either a new class of node is being used or the node class has to
> typically extended to many other machines and is likely more typing. The
> more typing can generally result in anomalies/errors in hosts.
>
> For example:
>
> node x1.y.z x2.y.z x3.y.z x4.y.z{
> ...
> ...
> }
>
> What I am trying to formulate this into is use the netgroup information
> available from /etc/netgroup and get this grouped as
>
> node @xN-y-z-hosts {
> ...
> ...
> }
>
> or
>
>
> nodegroup @xN-y-z-hosts {
> ...
> ...
> }
>
> What are the things that would possibly require the changes to?
>
> Thanks,
> Nikhil
>
> --
> 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/-/oB1zl_KR2MoJ.
> To post to this group, send email to puppet-users@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-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] using puppet to configure local settings

[Russell Van Tassell]

This works ... or you can just do a simple template if you don't wish to
use the arguments, as Mr. Horvath has done, below (which probably scales a
bit better)... just plug in the right ip address (and network name) for
your second server as-dictated from "facter" on that machine... I've used
10.0.0.1 with an eth0 interface, here.

-- begin resolv.conf.erb
nameserver 1.2.3.4
<% if network_eth0 == '10.0.0.1' -%>
nameserver 5.6.7.8
<% end -%>
-- end


On Thu, Mar 15, 2012 at 1:45 AM, Peter Horvath wrote:

> Hey,
>
> I am using this to configure resolve conf
> manifest:
> define resolv_conf($domainname = "$domain", $searchpath, $nameservers) {
>file { "/etc/resolv.conf":
>owner   => root,
>group   => root,
>mode=> 644,
>content => template("${module_name}/resolv.conf.erb"),
>}
>
> template:
>
> domain <%= domainname %>
> <% if !searchpath.empty? %>search <%= searchpath.join(" ") %>
> <% end -%>
> <% nameservers.each do |ns| %>nameserver <%= ns %>
> <% end -%>
>
> Node conf:
> resolv_conf { "1":
>domainname  => "domainname",
>searchpath  => [ "domainname", 'otherdomainname' ],
>nameservers => [ '10.66.3.12', '10.66.3.13' ],
>}
>
> I hope it helps
>
> On 15 March 2012 08:06, Sharuzzaman Ahmat Raslan 
> wrote:
> > Hi,
> >
> > I was asked by my boss if puppet can handle the following scenario.
> >
> > - 2 server (A and B)
> > - same config for each server, eg. /etc/resolv.conf (nameserver
> > 1.2.3.4)
> > - but B should have a local unique requirement of another nameserver
> > 5.6.7.8
> >
> > so, A will have
> > nameserver 1.2.3.4
> >
> > but B will have
> > nameserver 5.6.7.8
> > nameserver 1.2.3.4
> >
> > when we change the global nameserver 1.2.3.4 to 9.8.7.6, it should
> > become
> >
> > server A
> > nameserver 9.8.7.6
> >
> > server B
> > nameserver 5.6.7.8
> > nameserver 9.8.7.6
> >
> > This should be identical in how Red Hat Satellite is doing locally
> > managed files.
> >
> > See
> >
> http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.4/html/Reference_Guide/sect-Reference_Guide-Configuration.html#sect-Reference_Guide-Configuration-Locally_Managed_Files
> >
> > Any hint on how to achive the same thing with Puppet?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To post to this group, send email to puppet-users@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-users@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-users@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: zombie child process

[Russell Van Tassell]

My guess ... Just look in your puppet log to see what manifest ran last. At
one of my previous engagements, we routinely had zombied processes off of
puppet ... Eventually found an unclosed loop in a child process that was
causing it.

-- 
Russell M. Van Tassell
russel...@gmail.com

This message was sent using my wireless handheld device.
On Mar 3, 2012 2:09 AM, "Raboo"  wrote:

> > How do I begin looking on what can be wrong?
> > This error has appeared on both 2.7.6 and 2.7.11.
> Ok, a question to my own thread.
> Is there a way to set a timeout on both how long a class/module can
> run and a total timeout how long puppet can run it's catalog?
> That way I will actually find out which module that gets stuck, if
> there is a class timeout.
>
> --
> 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 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-users@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: puppet 2.7.11 requires ruby = 1.8.5

[Russell Van Tassell]

The gem includes everything you will need... the (basic) difference is
simply running "puppet agent" versus "puppet master" -- some packages just
hide the simplicity (probably a legacy thing?).

Note: I do not believe things like the sysconfig, logrotate and startup
scripts get installed by default with the gem (it's been a while since I've
done a fresh/virgin install in an environment) ... but those should be easy
enough to find. Many folks seem to run things out of cron, anyway...


On Fri, Mar 2, 2012 at 3:58 PM, rjl  wrote:

> I can only find the puppet gem. Isn't there a puppet-server gem? I have a
> working environment without rails. The following is installed on my puppet
> master:
>
> puppet-2.6.7-1.el5
> puppet-server-2.6.7-1.el5
>
> And the following is installed on my clients:
>
> puppet-2.6.7-1.el5
>
> You mention only one gem. Is there not a server gem? Obviously I am very
> confused.
>
> On Friday, March 2, 2012 4:28:10 PM UTC-7, Craig White wrote:
>>
>>
>> On Mar 2, 2012, at 3:43 PM, rjl wrote:
>>
>> > Thanks Michael,
>> > I have a working environment using ruby 1.8.5 (The Centos 5 default).
>> However, I want to change my puppet framework to be database driven. For
>> that, I  would like to use rails activerecord. Now the problem is that
>> rails is not supported in 1.8.5.
>> >
>> > Any suggestions would be greatly appreciated.
>> 
>> you're on the right track but on CentOS 5, you pretty much should forget
>> about using ruby/gems from rpm packages. Ruby 1.8.5 isn't going to get you
>> anywhere with a Rails application.
>>
>> Use gems...
>> gem install puppet
>> gem install rails
>>
>> Craig
>>
>>  --
> 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/-/LCusiYG84zoJ.
>
> To post to this group, send email to puppet-users@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-users@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: Puppet in NFS fools Facter

[Russell Van Tassell]

Any chance you copied over a bare metal box image, or something?

In any case, facter would seem to have only a handful of checks to
determine "virtual" or non-virtual... unfortunately I don't have a vmware
box in front of me to verify this, but you should be able to find facter's
"virtual" tests in some place like:

/usr/lib/ruby/1.[89]/facter/util/virtual.rb

(slightly more convoluted if you're running puppet under rvm)

At first glance, for VMWare, it appears to be looking for /proc/self/status
and/or /proc/virtual.


On Fri, Mar 2, 2012 at 3:42 PM, Forrie  wrote:

> I'm not sure I understand his setup, or what he means by "minimal
> install".
>
> My environment on the VMware image is CentOS 5.7, it is a full release
> and the NFS mount contains a full release of Puppet and Ruby 1.8.x.
>
> Perhaps there's something that Facter gets wrong when it's being
> called from a non-system location?
>
> Another possibility, is the previous run of Puppet was local -- each
> machine still has a local /var/lib/puppet layout with all the
> information that was stored (I'm not doing storedconfigs, yet).
> Could information in there play into this somehow.
>
>
> Thanks.
>
> --
> 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 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-users@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] Puppet in NFS fools Facter

[Russell Van Tassell]

Potentially related?

http://projects.puppetlabs.com/issues/10232


On Fri, Mar 2, 2012 at 2:44 PM, Forrie  wrote:

> I have Puppet mounted to a couple of machines via NFS (along with
> Ruby) -- and it works fine.   Except, I just noticed that it fools
> Facter in to believing it's a physical machine, when in fact one of
> them is a VMware host.
>
> We don't really use this setting, but I'm concerned other settings
> might not be accurate.
>
> Anyone know why this is happening?
>
>
> Thanks.
>
> --
> 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 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-users@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] Private key troubles after a new install and a reboot

[Russell Van Tassell]

Any chance you've hit one of those conditions where package defaults point
the SSLDIR to /var/lib/puppet/ssl instead of /etc/puppet/ssl? I've seen
this, specifically, when moving between RedHat/CentOS RPMs and gems, just
as an example. (or, they're specified one way in your puppet.conf, and
expected/defaulted differently in the package ... so in your second and
subsequent runs, you'll see the problem).

You should be able to easily reproduce this by blowing away all your puppet
configs and SSL information on a "new" client and cleaning them out on the
server ... then running "puppet agent --test" to see what it does (should
re-request certs, etc). Once it's done, immediately run it again to see if
it tries to re-request (and fail) the certs.

Hope that helps...
Russell


On Wed, Feb 29, 2012 at 12:55 PM, Tom  wrote:

> Ok, I'm new to puppet, but I've got everything working for my setup.
> Almost.
>
> I'm trying to set up a new server, using cobbler, and then puppet.
>
> CentOS 6.2
> Puppet 2.7.11
> Cobbler 2.0.11
>
> I have things set up so I can use kickstart to install the server on
> boot.  It installs puppet and facter from the puppetlabs repos and the
> snippet $SNIPPET('puppet_install_if_enabled') and
> $SNIPPET('puppet_register_if_enabled') is called in the %post section.
>
> I have the puppet server set up to autosign (for now).
>
> When the %post part of the kickstart install is run, I see the machine
> connecting to the puppetmaster, and it sets up the credentials:
>
> info: Could not find certificate for 'client.domain.com'
> info: Could not find certificate_request for 'client.domain.com'
> notice: client.domain.com has a waiting certificate request
> notice: Signed certificate request for client.domain.com
> notice: Removing file Puppet::SSL::CertificateRequest
> client.domain.com at '/var/lib/puppet/ssl/ca/requests/
> client.domain.com.pem'
>
>
>
>
> But when I reboot the machine, if I try to run puppetd again manually,
> I'm getting a private key error:
>
>
> puppetd --server puppet.domain.com --test --waitforcert 15
> err: Could not request certificate: The certificate retrieved from the
> master does not match the agent's private key.
> Certificate fingerprint: E5:B1:52:B2:DC:DE:8C:DE:A7:AF:ED:
> 19:C8:E3:F5:12
> To fix this, remove the certificate from both the master and the agent
> and then start a puppet run, which will automatically regenerate a
> certficate.
> On the master:
>  puppet cert clean client.domain.com
> On the agent:
>  rm -f /var/lib/puppet/ssl/certs/client.domain.com.pem
>  puppet agent -t
>
> If I do what it says, then puppet gets new certs (I guess that's what
> it's doing) and everything works fine.
>
> But I cannot figure out why that is required.  What is going wrong?
> Shouldn't it be able to come up and work without jumping through these
> extra hoops?
>
> Tom
>
> --
> 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 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-users@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: Struggle with erb syntax

[Russell Van Tassell]

On Tue, Feb 21, 2012 at 5:32 PM, thinkwell wrote:

> Shazzam - it worked; yet I had made no changes. :-( Very nice it's
> working, but why the earlier "err: Could not retrieve catalog from
> remote server: wrong header line
> format" that cost me so much time? Seems buggy, but I reckon it's me,
> the learning puppet user.
>

Any chance your puppet server is working overtime? Running behind webrick,
or something else? I've noticed some weird "unexplained" errors when the
server starts to get busy...

-- 
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 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] "SSLv3 read server certificate B: certificate verify failed." -- Not time related

[Russell Van Tassell]

Just a couple of issues...

On Tue, Feb 21, 2012 at 4:56 PM, Jon Davis  wrote:

> I recently built, added to puppet and then nuked a server.  Before I
> re-added the machine (after I rebuilt it, with the same name), I went to
> the puppet server and ran `puppet cert revoke dev-8.company.com` and
> `puppet cert clean dev-8.company.com`.  Now when puppet runs on ANY
> server in my environment, they get the following error:
>
> info: Caching certificate for dev-8.company.com
> *err: Could not retrieve catalog from remote server: SSL_connect
> returned=1 errno=0 state=SSLv3 read server certificate B: certificate
> verify failed.  This is often because the time is out of sync on the server
> or client*
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> *err: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3
> read server certificate B: certificate verify failed.  This is often
> because the time is out of sync on the server or client*
>
>
> Now I know for a fact that it isn't a time issue because the puppet server
> is on NTP as are the clients.  The new machine is also within 1-2 seconds
> of server time.
>

For "normal" NTP clients, this would imply that your time sync is off by a
few factors (ie. your time differences should be mere fractions of seconds
off between servers if your NTP setup is working correctly).


>  All of the clients are configured to run (via Cron) `/usr/sbin/puppetd
> --onetime --no-daemonize --logdest syslog --server puppet.company.com`.
>  The server is named puppet-1.company.com but puppet. is a valid cname.
>  I've tried rebooting the puppet server, I've tried upgrading it, just
> about anything I can think of.
>

If the reverse (IN-ADDR) of your puppet server is going to return
puppet.company.com as its name, but you are connecting to foo.company.com,
that's pretty much a textbook SSL error (ie. your SSL certificate doesn't
match the name it's claiming to be). What happens if you delete the SSL
cert on the client, and re-run the CSR by pointing at the real name of the
server?

Hope that helps...

Russell

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@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] Why are not the reports uploading?

[Russell Van Tassell]

The silly question... that's in the agent's puppet.conf, not just in the
agent section of the puppet.conf on the puppet master? Have you restarted
the server and agents? Do you see anything written to
/var/lib/puppet/reports at all? Is it writable by the puppet user? Do you
see any obvious errors in any of the logs? Do you see the reports being
posted to /var/lib/puppet/log/masterhttp.log?


On Wed, Feb 8, 2012 at 1:53 PM, Peter Berghold wrote:

> That's in there.
>
> Each of the hosts running the agent already have that in there...
>
>
>
> On Wed, Feb 8, 2012 at 4:27 PM, Russell Van Tassell 
> wrote:
>
>> Immediately before that, did you miss the agent configuration?
>>
>>   # puppet.conf (on each agent)
>>   [agent]
>> report = true
>>
>>
>>
>>
>> On Wed, Feb 8, 2012 at 1:16 PM, Peter Berghold 
>> wrote:
>>
>>> Hi folks,
>>>
>>> After installing dashboard after follwing the instructions here:
>>> http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
>>>
>>> I find that the reports are not uploading.   In my puppet.conf the
>>> [master] section has the following:
>>>
>>> # Dashboard stuff
>>> reports = store, html
>>> reporturl = http://206.217.196.46:3000/reports/upload
>>>
>>>
>>> puppet version is: 2.7.10
>>>
>>> Neither the output from the webbrick server show the uploads happening
>>> nor the generated web page.  I have the delayed job processors running and
>>> I'm beginning to think I've lost my mind...
>>>
>>>
>>>
>>> --
>>> Peter L. Berghold
>>> Owner, Shark River Technical Solutions LLC
>>>
>>> --
>>> 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 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-users@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.
>>
>
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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 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-users@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] Questions regarding Puppet with httpd.conf

[Russell Van Tassell]

On Wed, Feb 8, 2012 at 3:46 PM, the_fonz  wrote:

> Hi,
>
> I'd like to start using Puppet to manage an httpd.conf file across
> several webservers.


Others have already correctly steered you towards templates for this sort
of thing, but I have one aside...


> each httpd.conf
> file has multiple Virtual Host entries that are defined by the
> webservers IP.  for example.
>

Just like to point out that, unless you have specific reason for binding
apache only to one interface, it's perfectly acceptable to throw wildcards
in to these declarations (ie. software virtual hosting versus hardware). It
has the added effect of simplifying configurations (though, as I hinted at
previously, there may be other security related implications or similar
that prevents you from doing this sort of thing).

-- 
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 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] Why are not the reports uploading?

[Russell Van Tassell]

Immediately before that, did you miss the agent configuration?

  # puppet.conf (on each agent)
  [agent]
report = true




On Wed, Feb 8, 2012 at 1:16 PM, Peter Berghold wrote:

> Hi folks,
>
> After installing dashboard after follwing the instructions here:
> http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html
>
> I find that the reports are not uploading.   In my puppet.conf the
> [master] section has the following:
>
> # Dashboard stuff
> reports = store, html
> reporturl = http://206.217.196.46:3000/reports/upload
>
>
> puppet version is: 2.7.10
>
> Neither the output from the webbrick server show the uploads happening nor
> the generated web page.  I have the delayed job processors running and I'm
> beginning to think I've lost my mind...
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> 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 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-users@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] I think I have a stray directory on my PuppetMaster

[Russell Van Tassell]

The directory that probably represents is /etc/puppet/manifests (with an
"s")... however, not seeing your puppet installation, there is a chance
that it could be "needed" for something. The best bet is probably to
(temporarily) move it out of the way and see if things start complaining
(puppet agent --test) or break.


On Wed, Jan 25, 2012 at 9:48 AM, Dan White  wrote:

> Can anyone offer a reason for having a folder with a path of
> /etc/puppet/modules/manifest ?
>
> I think I got overzealous making
> /etc/puppet/modules//manifest directories, but I am still new
> enough to Puppet to be unsure -- and I am smart enough NOT to just delete
> it without checking with a reference or a more knowledgable person.
>
> Thanks, folks.
>
> Reject mediocrity !
>
> "Shared pain is lessened; shared joy, increased - thus do we refute
> entropy !" Spider Robinson
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> 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 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-users@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] Puppet Dashboard: db:migrate failure (1.2.2 to 1.2.4)

[Russell Van Tassell]

On Tue, Jan 3, 2012 at 4:30 PM, Daniel Pittman wrote:

> On Tue, Jan 3, 2012 at 16:01, Russell Van Tassell 
> wrote:
>
> > For completeness sake, the subsequent error (with trace) is thus... I
> think
> > at this point, I'm likely stuck -- at least short of wiping the DB and
> > starting over, fresh (which I'd prefer to not do).
>
> Both of those look like MySQL level errors - not specifically about
> this database; the first should be resolvable by rebuilding the table
> to reduce the number of locks required, according to the MySQL people.
>

...I just bumped the  innodb_buffer_pool_size as recommended by an old bug.
That seemed to make that go away... 8M is a little silly, anyway...

-- begin my.cnf excerpt
# Default of 8MB for innodb buffer pool is a little small - 2011/01/03 RVT
#  - Ref: http://bugs.mysql.com/bug.php?id=15667
innodb_buffer_pool_size = 83886080
-- end


For the second, you might need to drop the foreign key constraints by
> hand, because table changes are not transactional in MySQL.  :(  I
> keep forgetting that, being used to a competent ^W fully transactional
> DBMS.
>
> You should be able to hand-write the appropriate delete constraint
> SQL, though, if you want.  It isn't that hard.
>

Okay... looks like I'm in an iterative process, now... this has allowed me
to get past the reports table..

-- begin
 mysql> show create table reports;
| reports | CREATE TABLE `reports` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `node_id` int(11) DEFAULT NULL,
  `host` varchar(255) DEFAULT NULL,
  `time` datetime DEFAULT NULL,
  `status` varchar(255) DEFAULT NULL,
  `kind` varchar(255) DEFAULT NULL,
  `puppet_version` varchar(255) DEFAULT NULL,
  `configuration_version` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_reports_on_node_id` (`node_id`),
  KEY `index_reports_on_time_and_node_id_and_status`
(`time`,`node_id`,`status`),
  CONSTRAINT `fk_reports_node_id` FOREIGN KEY (`node_id`) REFERENCES
`nodes` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=594242 DEFAULT CHARSET=utf8 |
1 row in set (0.00 sec)

mysql> SET FOREIGN_KEY_CHECKS=0;
mysql> alter table reports drop foreign key `fk_reports_node_id`;
mysql> SET FOREIGN_KEY_CHECKS=1;
-- end

...and now I'm on to resource_statuses for a similar problem.  Looks like
it's time to dump this in a screen session and let it run until I hit the
next big boom (ie. and then try to fix it from home, rinse, repeat, etc).


-- begin
-- execute("ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN
KEY (node_id) REFERENCES nodes(id) ON DELETE CASCADE;")
   -> 27.5650s
-- execute("ALTER TABLE resource_events ADD CONSTRAINT
fk_resource_events_resource_status_id FOREIGN KEY (resource_status_id)
REFERENCES resource_statuses(id) ON DELETE CASCADE;")
   -> 903.3903s
-- execute("ALTER TABLE resource_statuses ADD CONSTRAINT
fk_resource_statuses_report_id FOREIGN KEY (report_id) REFERENCES
reports(id) ON DELETE CASCADE;")
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: The table '#sql-5675_a' is full: ALTER TABLE
resource_statuses ADD CONSTRAINT fk_resource_statuses_report_id FOREIGN KEY
(report_id) REFERENCES reports(id) ON DELETE CASCADE;
-- end

-- 
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 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] Puppet Dashboard: db:migrate failure (1.2.2 to 1.2.4)

[Russell Van Tassell]

For completeness sake, the subsequent error (with trace) is thus... I think
at this point, I'm likely stuck -- at least short of wiping the DB and
starting over, fresh (which I'd prefer to not do).



-- begin
-- execute("ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN
KEY (node_id) REFERENCES nodes(id) ON DELETE CASCADE;")
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: Can't create table 'puppet_dashboard.#sql-5675_5' (errno:
121): ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN KEY
(node_id) REFERENCES nodes(id) ON DELETE CASCADE;
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:227:in
`log'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:324:in
`execute'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:352:in
`send'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:352:in
`method_missing'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:328:in
`say_with_time'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:328:in
`say_with_time'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:348:in
`method_missing'
./db/migrate//2018204121_add_report_foreign_key_constraints.rb:10:in
`up_without_benchmarks'
./db/migrate//2018204121_add_report_foreign_key_constraints.rb:13:in
`call'
./db/migrate//2018204121_add_report_foreign_key_constraints.rb:13:in
`up_without_benchmarks'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:282:in
`send'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:282:in
`migrate'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:282:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:365:in
`__send__'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:365:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:491:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:567:in
`call'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:567:in
`ddl_transaction'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:490:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:477:in
`each'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:477:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:401:in
`up'
/opt/puppet-dashboard-1.2.4/vendor/rails/activerecord/lib/active_record/migration.rb:383:in
`migrate'
/opt/puppet-dashboard-1.2.4/vendor/rails/railties/lib/tasks/databases.rake:112
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in
`invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in
`invoke_with_call_chain'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in
`invoke_task'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in
`top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in
`each'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in
`top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in
`standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in
`top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in
`standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
Tasks: TOP => db:migrate

-- end

-- 
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 this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?

Re: [Puppet Users] Puppet Dashboard: db:migrate failure (1.2.2 to 1.2.4)

[Russell Van Tassell]

On Tue, Jan 3, 2012 at 2:58 PM, Daniel Pittman wrote:

> On Tue, Jan 3, 2012 at 14:52, Russell Van Tassell 
> wrote:
>
> > Mysql::Error: The total number of locks exceeds the lock table size:
> ALTER
> > TABLE resource_events ADD CONSTRAINT
> fk_resource_events_resource_status_id
> > FOREIGN KEY (resource_status_id) REFERENCES resource_statuses(id) ON
> DELETE
> > CASCADE;
>
> Wow.  I don't think I have seen a "total number of locks too big"
> error before.  You need to tune MySQL to have a bigger lock table size
> for this to work.  On the plus side, once you do that, run the
> migration thing again and it should pick up from where it left off.
>
>
Yeah, I've tried re-running it already, and now it's breaking on something
else...

(BTW, it doesn't actually pick up where it left off ... it still re-runs
the deletes - though they run a little bit faster ,now)


-- begin
-- execute("ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN
KEY (node_id) REFERENCES nodes(id) ON DELETE CASCADE;")
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: Can't create table 'puppet_dashboard.#sql-78e_f3d' (errno:
121): ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN KEY
(node_id) REFERENCES nodes(id) ON DELETE CASCADE;

Tasks: TOP => db:migrate
(See full trace by running task with --trace)
-- end

-- 
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 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] Puppet Dashboard: db:migrate failure (1.2.2 to 1.2.4)

[Russell Van Tassell]

An error I managed to hit today, trying to migrate puppet dashboard from
1.2.2 to 1.2.4 (after upgrading the master to puppet 2.7.9 seemed to
prevent the dashboard from importing new reports).  I'm trying to re-run it
now, but as you might guess, the DB is pretty huge and the process takes a
while to execute.

Executed from the puppet-dashboard directory: sudo rake db:migrate
RAILS_ENV=production


==  AddReportForeignKeyConstraints: migrating
=
Going to delete orphaned records from metrics, report_logs,
resource_statuses, resource_events
Preparing to delete from metrics
2012-01-03 14:16:07: Deleting 0 orphaned records from metrics
Deleting   100% |##| Time:
00:00:00

Preparing to delete from report_logs
2012-01-03 14:16:41: Deleting 0 orphaned records from report_logs
Deleting   100% |##| Time:
00:00:00

Preparing to delete from resource_statuses
2012-01-03 14:16:51: Deleting 0 orphaned records from resource_statuses
Deleting   100% |##| Time:
00:00:00

Preparing to delete from resource_events
2012-01-03 14:19:13: Deleting 0 orphaned records from resource_events
Deleting   100% |##| Time:
00:00:00

-- execute("ALTER TABLE reports ADD CONSTRAINT fk_reports_node_id FOREIGN
KEY (node_id) REFERENCES nodes(id) ON DELETE CASCADE;")
   -> 96.6684s
-- execute("ALTER TABLE resource_events ADD CONSTRAINT
fk_resource_events_resource_status_id FOREIGN KEY (resource_status_id)
REFERENCES resource_statuses(id) ON DELETE CASCADE;")
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: The total number of locks exceeds the lock table size: ALTER
TABLE resource_events ADD CONSTRAINT fk_resource_events_resource_status_id
FOREIGN KEY (resource_status_id) REFERENCES resource_statuses(id) ON DELETE
CASCADE;

Tasks: TOP => db:migrate
(See full trace by running task with --trace)


On a side note, this process is rather noisy, firing off a bunch of
warnings from the start:

NOTE: Gem.source_index is deprecated, use Specification. It will be removed
on or after 2011-11-01.
Gem.source_index called from
/opt/puppet-dashboard-1.2.4/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21.
NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It
will be removed on or after 2011-11-01.
Gem::SourceIndex#initialize called from
/opt/puppet-dashboard-1.2.4/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
It will be removed on or after 2011-11-01.
Gem::SourceIndex#add_spec called from
/usr/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91.
NOTE: Gem::SourceIndex#add_spec is deprecated, use Specific

Re: [Puppet Users] In CentOS 6, puppet Unresponsive

[Russell Van Tassell]

On Fri, Dec 30, 2011 at 7:05 AM, Craig White  wrote:

>
> On Dec 30, 2011, at 3:36 AM, Russell Van Tassell wrote:
>
> > You can use RVM, or getting a ruby 1.8.7 build/rpm shouldn't be that
> difficult (I will have to look at our source, tomorrow, but we store a
> similar thing in our own local EL repo, pretty much for puppet and one or
> two other things ... At this hour I can't remember if we compiled it or
> grabbed it from a reputable upstream repository, however).
> 
> OP is talking about puppet version, you are talking about ruby version...
> two different things.
>

Ummm... the thread changed a bit (and you cut out the pertinent part of the
prior message). At least to me, it sounded like the OP was also questioning
the Ruby version. From the message immediately prior to mine (which you
conveniently snipped out - emphasis is mine):

-- begin
On Dec 30, 2011 2:31 AM, "Juan-Francisco Diez"  wrote:
Thank to all. We try to put the server in the newest version. *But with ruby
* in CentOS it's a bit more complicated because the new version is not
packaged in the 5.x version.
-- end

-- 
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 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] In CentOS 6, puppet Unresponsive

[Russell Van Tassell]

You can use RVM, or getting a ruby 1.8.7 build/rpm shouldn't be that
difficult (I will have to look at our source, tomorrow, but we store a
similar thing in our own local EL repo, pretty much for puppet and one or
two other things ... At this hour I can't remember if we compiled it or
grabbed it from a reputable upstream repository, however).

-- 
Russell M. Van Tassell
russel...@gmail.com

This message was sent using my wireless handheld device.
On Dec 30, 2011 2:31 AM, "Juan-Francisco Diez"  wrote:

> Thank to all. We try to put the server in the newest version. But with
> ruby in CentOS it's a bit more complicated because the new version is not
> packaged in the 5.x version.
>
> I will try to put all in the same version
>
> 2011/12/30 Russell Van Tassell 
>
>> Similarly, I believe the docs very clearly say (in one or more places)
>> that your server always needs to be the newest version out of any of your
>> clients (ie. The server is usually happy/fine to deal with older clients
>> (with a few potential exceptions), but a newer client may not work with an
>> older server).
>>
>> --
>> Russell M. Van Tassell
>> russel...@gmail.com
>>
>> This message was sent using my wireless handheld device.
>> On Dec 30, 2011 1:18 AM, "Denmat"  wrote:
>>
>>> Hi,
>>>
>>> Will need to see logs but generally you cant have the master at an older
>>> version than the clients - if I remember correctly.
>>>
>>> Cheers,
>>>  Den
>>>
>>> On 30/12/2011, at 19:49, Juan-Francisco Diez  wrote:
>>>
>>> Hi all,
>>>
>>> We have the server installed in CentOS 5.7. The version installed of
>>> puppet-server is 2.7.1.
>>>
>>> Some puppet clients have installed CentOS 6.x and the version 2.7.9 of
>>> puppet client.
>>>
>>> The problem we have is that the puppet client become unresponsive after
>>> a few minutes. All we can see through the logs of the client is that the
>>> puppet is running but never end. We see the process through a "ps" command
>>> but it never finish. If we restart the service the node work properly for a
>>> few minutes.
>>>
>>> We try updating the ruby and all of gems, the OS with the lastest packet
>>> but the problem still present. We don't know why it occurs. Also another
>>> nodes with the same packets and configuration work fine.
>>>
>>> I hope someone can help with this trouble.
>>>
>>> Happy new year to all of us.
>>>
>>> Best Regards,
>>> Juan-Francisco Diez Léglise
>>>
>>> --
>>> 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 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-users@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-users@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-users@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-users@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] In CentOS 6, puppet Unresponsive

[Russell Van Tassell]

Similarly, I believe the docs very clearly say (in one or more places) that
your server always needs to be the newest version out of any of your
clients (ie. The server is usually happy/fine to deal with older clients
(with a few potential exceptions), but a newer client may not work with an
older server).

-- 
Russell M. Van Tassell
russel...@gmail.com

This message was sent using my wireless handheld device.
On Dec 30, 2011 1:18 AM, "Denmat"  wrote:

> Hi,
>
> Will need to see logs but generally you cant have the master at an older
> version than the clients - if I remember correctly.
>
> Cheers,
> Den
>
> On 30/12/2011, at 19:49, Juan-Francisco Diez  wrote:
>
> Hi all,
>
> We have the server installed in CentOS 5.7. The version installed of
> puppet-server is 2.7.1.
>
> Some puppet clients have installed CentOS 6.x and the version 2.7.9 of
> puppet client.
>
> The problem we have is that the puppet client become unresponsive after a
> few minutes. All we can see through the logs of the client is that the
> puppet is running but never end. We see the process through a "ps" command
> but it never finish. If we restart the service the node work properly for a
> few minutes.
>
> We try updating the ruby and all of gems, the OS with the lastest packet
> but the problem still present. We don't know why it occurs. Also another
> nodes with the same packets and configuration work fine.
>
> I hope someone can help with this trouble.
>
> Happy new year to all of us.
>
> Best Regards,
> Juan-Francisco Diez Léglise
>
> --
> 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 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-users@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-users@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] Puppet-dashboard and centos5

[Russell Van Tassell]

Part of the problem with that is the EPEL RPM is not 5.4, not 5.3 (as
detailed in that document).

Although, we have a number of CentOS 5.x boxes running Ruby 1.8.7 ... I had
*thought* our original source was the EPEL repo, but could be mistaken.


On Tue, Dec 27, 2011 at 5:02 PM, Doug Chapman  wrote:

> Based on some older threads on this list (eg: 'dropping support for
> ruby 1.85?') and my own painful discovery process, it might be time to
> remove the Centos5.5 section from this page:
>
> http://docs.puppetlabs.com/guides/installing_dashboard.html#installation
>
> Also, the puppet-dashboard package doesn't exists (anymore?) for
> centos5 in the puppet labs yum repo.
>
> --
> Doug Chapman
>
> --
> 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 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-users@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 puppet agent on Windows XP

[Russell Van Tassell]

On Mon, Nov 21, 2011 at 5:31 PM, Jacob Helwig  wrote:

> On 2011-11-21 12:50 , Jeff Sussna wrote:
> > Trying to get Puppet 2.7.6/Facter 1.6.2 running on Windows XP SP3.
> > [...]
>
> Anyone have success getting puppet running on XP?
>
> Right now, Puppet & Facter are only supported on Server 2003 & Server
> 2008, since those are the only platforms we tested against when working
> on the Windows support.


I would imagine that you could get it to work with Cygwin (under cygrunsrv)
on "any" Windows platform ... the SSH server there is already quite
reasonable, and Cygwin has a pre-built Ruby (among other similar scripting
languages); I've had the pleasure of setting up distributed build
environments through such mechanisms, so I'd not think puppet would be that
much of a stretch. I could be wrong, though...

-- 
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 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] working thru tutorial

[Russell Van Tassell]

You can setup a "pattern" with a regular expression to weed-out the process
list if you don't use "hasstatus"

http://docs.puppetlabs.com/references/latest/type.html#service

...but, sounds like you nailed it.



On Wed, Nov 16, 2011 at 12:18 PM, Matthew O'Connor  wrote:

> That fixed it.
>
> Oh, I think I see what's going on:
>
> When I run `puppet httpd.pp`, it runs `ps` and finds a process with
> `httpd` in the name and so concludes the service is running. If I rename
> the script to something else then Puppet no longer finds any process with
> 'httpd' in its name.
>
> Perhaps Puppet should have a check that prevents thinking it is the
> satisfying service?
>
> Thanks,
> Matt
>
>
> On Wed, Nov 16, 2011 at 12:54 PM, Nan Liu  wrote:
>
>> On Wed, Nov 16, 2011 at 2:14 PM, Matthew O'Connor
>>  wrote:
>> > I looked for that. There's not any other http daemon running. The PID
>> that
>> > the first returns changes every time (now at 23052, 23139, etc.). The
>> second
>> > one never returns a PID (unless there's actually an httpd running).
>> >
>>
>> Add hasstatus so it uses service instead of ps -ef for checking the
>> service:
>>
>>   service { 'httpd':
>> ensure => running,
>> enable => true,
>>  hasstatus => true,
>>   }
>>
>> Thanks,
>>
>> Nan
>>
>> --
>> 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 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-users@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-users@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] working thru tutorial

[Russell Van Tassell]

Do you have another http daemon running, by chance? If I'm reading this
right, the first run seems to think it found another httpd server on PID
17243 - what's running on that process?



On Wed, Nov 16, 2011 at 9:37 AM, Matthew O'Connor
wrote:

> When I run `puppet apply --verbose --debug httpd.pp`, the last lines
> printed are:
>
> debug: Finishing transaction -608038528
> debug: Loaded state in 0.00 seconds
> info: Applying configuration version '1321356508'
> debug: Service[httpd](provider=redhat): Executing 'ps -ef'
> debug: Service[httpd](provider=redhat): PID is 17243
> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
> httpd'
> debug: Finishing transaction -608222128
> debug: Storing state
> debug: Stored state in 0.01 seconds
>
>  When I run `puppet apply --verbose --debug start.pp`, the last lines
> printed are:
>
> debug: Finishing transaction -607971218
> debug: Loaded state in 0.00 seconds
> info: Applying configuration version '1321356691'
> debug: Service[httpd](provider=redhat): Executing 'ps -ef'
> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
> httpd'
> debug: Service[httpd](provider=redhat): Executing '/sbin/service httpd
> start'
> debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
> httpd'
> notice: /Stage[main]//Service[httpd]/ensure: ensure changed 'stopped' to
> 'running'
> debug: Finishing transaction -608154818
> debug: Storing state
> debug: Stored state in 0.01 seconds
>
> I made sure to stop `httpd` before each run. `start.pp` and `httpd.pp`
> have the same contents.
>
> Any other thoughts?
>
>
> On Wed, Nov 16, 2011 at 9:00 AM, Christopher Wood <
> christopher_w...@pobox.com> wrote:
>
>> On Tue, Nov 15, 2011 at 04:40:29PM -0800, Matthew O'Connor wrote:
>> > Hi all,
>> >
>> > I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
>> > manifests.html) using the VM provided (http://www.puppetlabs.com/
>> > downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
>> > asked to write a manifest that ensures httpd is running, I wrote:
>> >
>> > service { 'httpd':
>> >   ensure => running,
>> >   enable => true,
>> > }
>> >
>> > I named this manifest "httpd.pp". When I ran `puppet apply httpd.pp`
>> > nothing happens. If I rename this manifest to something else `puppet
>> > apply` works as I would expect.
>>
>> puppet apply --debug --verbose httpd.pp
>>
>> If the service is already running and enabled then puppet won't do
>> anything.
>>
>> > This was/is extremely confusing. I figured what better way to name the
>> > manifest than to name the service it's ensuring. Is this a known
>> > issue? Documentation problem? Something else?
>>
>> I don't know that filenames of manifests affect anything. Running with
>> debug and verbose flags as above will show you more about what's going on.
>>
>> > Thanks for you help.
>> >
>> > Matthew
>> >
>> > --
>> > 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 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-users@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-users@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-users@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] How-To Question: Installing a "service" that does not come in an RPM ?

[Russell Van Tassell]

It might be helpful to include the O/S you're asking about, possibly with
the package... sometimes it's a matter of just changing/adding a
respository. Sometimes it might be a little more involved.


On Tue, Oct 18, 2011 at 1:21 PM, Dan White  wrote:

> Are there any exapmples out there that show an intelligent way to do this ?
>
> My searches are not turning up anything useful
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> 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 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-users@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: Puppet on Centos 6.0

[Russell Van Tassell]

To be clear, the "Wrong Elf Class" error simply means that you are trying to
mix 32 and 64 bit binaries... and the compiler isn't going to allow that...
so, look at Ruby and MySQL -- at least one of them is different.

You can look at the file type by using "file" and the filename. For example,
from a CentOS 6.x (32-bit/i686/i386) puppet host:

$ file /usr/lib/ruby/1.8/thread.so
/usr/lib/ruby/1.8/thread.so: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), dynamically linked, stripped
$ file /usr/lib/mysql/libmysqlclient_r.so.16.0.0
/usr/lib/mysql/libmysqlclient_r.so.16.0.0: ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), dynamically linked, stripped
$ file `which ruby`
/usr/bin/ruby: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

Hope that helps...
Russell



On Mon, Oct 17, 2011 at 1:42 PM, robert.morti...@gmail.com <
robert.morti...@gmail.com> wrote:

>
>
> On Oct 17, 9:26 pm, Russell Van Tassell  wrote:
> > This looks like you have a 32-bit Ruby and are trying to link to the
> 64-bit
> > MySQL.
> >
> > On Mon, Oct 17, 2011 at 1:24 PM, robert.morti...@gmail.com <
> >
> installed
>
> yum list | grep ruby
> ruby.x86_64
> 1.8.7.299-5.el6_0.1   @updates
>
> >
> >
> >
> >
> >
> >
> > robert.morti...@gmail.com> wrote:
> >
> > > On Oct 17, 9:05 pm, Todd Zullinger  wrote:
> > > > robert.morti...@gmail.com wrote:
> > > > > I am having no joy installing Puppet Server with MySQL support from
> > > > > the EPEL on Centos 6. The active record support for MySQL seems to
> be
> > > > > missing. Has anyone seen a good howto for this?
> >
> > > > Sadly, rubygem-rails is not built for EL-6.  You can either rebuild
> > > > the 2.3.8 packages from Fedora or find someone to act as a maintainer
> > > > for these in EPEL.
> >
> > > But the puppet was from the epel, I sort of assumed it would have the
> > > correct mysql
> >
> > > When I attempt the gem install I get:-
> >
> > >  gem install mysql --with-mysql-include=/usr/include/mysql --with-
> > > mysql-libs=/usr/lib64/mysql
> > > /usr/lib/ruby/1.8/thread.so: /usr/lib/ruby/1.8/thread.so: wrong ELF
> > > class: ELFCLASS32 - /usr/lib/ruby/1.8/thread.so (LoadError)
> > >from /usr/lib/ruby/1.8/thread.rb:5
> > >from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:11:in `require'
> > >from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:11
> > >from /usr/bin/gem:8:in `require'
> > >from /usr/bin/gem:8
> >
> > > I have mysql-develop, the ruby dev and gcc installed
> >
> > > > --
> > > > ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL:
> www.pobox.com/~tmz/pgp <http://www.pobox.com/%7Etmz/pgp><
> http://www.pobox.com/%7Etmz/pgp>
> > > >
> ~~
> > > > A word to the wise ain't necessary -- it's the stupid ones who need
> > > > the advice.
> > > > -- Bill Cosby
> >
> > > >  application_pgp-signature_part
> > > > < 1KViewDownload
> >
> > > --
> > > 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 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-users@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-users@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: Puppet on Centos 6.0

[Russell Van Tassell]

This looks like you have a 32-bit Ruby and are trying to link to the 64-bit
MySQL.


On Mon, Oct 17, 2011 at 1:24 PM, robert.morti...@gmail.com <
robert.morti...@gmail.com> wrote:

>
>
> On Oct 17, 9:05 pm, Todd Zullinger  wrote:
> > robert.morti...@gmail.com wrote:
> > > I am having no joy installing Puppet Server with MySQL support from
> > > the EPEL on Centos 6. The active record support for MySQL seems to be
> > > missing. Has anyone seen a good howto for this?
> >
> > Sadly, rubygem-rails is not built for EL-6.  You can either rebuild
> > the 2.3.8 packages from Fedora or find someone to act as a maintainer
> > for these in EPEL.
>
>
> But the puppet was from the epel, I sort of assumed it would have the
> correct mysql
>
> When I attempt the gem install I get:-
>
>  gem install mysql --with-mysql-include=/usr/include/mysql --with-
> mysql-libs=/usr/lib64/mysql
> /usr/lib/ruby/1.8/thread.so: /usr/lib/ruby/1.8/thread.so: wrong ELF
> class: ELFCLASS32 - /usr/lib/ruby/1.8/thread.so (LoadError)
>from /usr/lib/ruby/1.8/thread.rb:5
>from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:11:in `require'
>from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:11
>from /usr/bin/gem:8:in `require'
>from /usr/bin/gem:8
>
> I have mysql-develop, the ruby dev and gcc installed
>
> >
> > --
> > ToddOpenPGP -> KeyID: 0xBEAF0CE3 | 
> > URL:www.pobox.com/~tmz/pgp
> > ~~
> > A word to the wise ain't necessary -- it's the stupid ones who need
> > the advice.
> > -- Bill Cosby
> >
> >  application_pgp-signature_part
> > < 1KViewDownload
>
> --
> 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 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-users@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: Puppet on Centos 6.0

[Russell Van Tassell]

Personally, I've had better luck letting gem managed its own gems, rather
than depending on Yum repositories (specifically on CentOS).

I'd take a list of the Ruby gems you've installed via rpm (rpm -q -a | grep
ruby) and then consider installing them directly, as so:

% sudo gem install mysql
% sudo gem list

Regards,
Russell


On Mon, Oct 17, 2011 at 12:57 PM, robert.morti...@gmail.com <
robert.morti...@gmail.com> wrote:

>
>
> On Oct 17, 4:00 pm, "robert.morti...@gmail.com"
>  wrote:
> > On Oct 17, 3:46 pm, Dominik Zyla  wrote:
> >
> > > On 10/17/2011 04:14 PM, robert.morti...@gmail.com wrote:
> >
> > > > I am having no joy installing Puppet Server with MySQL support from
> > > > the EPEL on Centos 6. The active record support for MySQL seems to be
> > > > missing. Has anyone seen a good howto for this?
> >
> > > You would need to install mysql library for Ruby. It should be packed
> in
> > > Centos.
> >
> > > --
> > > Dominik Zyla
> >
> > OK I was getting
> > "ERROR:  Could not find a valid gem 'ActiveRecord' (>= 0) in any
> > repository"
> > And that was sending me off on a wild goose chase across the internet
> > looking for a Centos 6 ActiveRecord.
> >
> Still no joy I get this on the master when I run the client:
>
>  Could not connect to database: Please install the mysql adapter: `gem
> install activerecord-mysql-adapter` (Could not find RubyGem mysql (~>
> 2.8.1)#012)
>
> ruby-mysql.x86_64 is installed but is ruby-mysql.x86_64  2.8.2-1.el6
> from the epel
>
> Config is as follows (not real password)
>
> [master]
> storeconfigs = true
> dbadapter = mysql
> dbuser = puppet
> dbpassword = PASSWORD_HR
> dbserver = lsg-cbp-mysql01
> dbname = puppet
> #dbsocket = /var/lib/mysql/mysql.sock
>
> Connection string can be used to connect to DB server from puppet
> server command line
>
> Do I need the Exact ruby mysql?
>
> > Found it just as I came back to check
> >
> > Rob
>
> --
> 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 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-users@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] [Dashboard] permission denied error when using apache

[Russell Van Tassell]

Just FYI/FWIW ... Passenger tries to run (setuid) as the user that owns
config.ru... not as the apache user.

Ref: http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger


On Tue, Sep 27, 2011 at 7:30 AM, Tom De Vylder  wrote:

> On 27 Sep 2011, at 16:10, Scott Smith wrote:
>
> Check the exception. It's trying to rm all.js
>
>
> The same happens with stylesheets/all.css.
> Both files don't exist on the filesystem, nor are they supplied in the
> package.
>
> # dpkg -c puppet-dashboard_1.2.1-1_all.deb | grep -iE 'all.css|all.js'
> #
>
> I don't get why this fails with Apache/Passenger and not with Webrick.
>
> TomDV
>
> --
> 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 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-users@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] Email Protection? (NON SUBJECT ORIENTED)

[Russell Van Tassell]

On Thu, Sep 15, 2011 at 7:46 AM, Nigel Kersten  wrote:

>
> Seriously, it is Google Groups, so you get the protection it offers,
> requiring logins and CAPTCHA to view full email addresses on the web
> archives, etc etc, but it's difficult to stop people subscribing to lists
> and collecting addresses that way.
>
>
That's one good argument to use a unique address for email list
subscriptions, right there... particularly if your junk mail filter is not
up to snuff. Using a gmail address for google groups has always seemed like
a reasonable compromise, to me (and my "personal" and "professional"
addresses are kept separate, of course). Care *always* should be taken when
you're "taking an email address public."

Regards,
Russell

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@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] Problems installing Puppet Dashoboard

[Russell Van Tassell]

Just a stab in the dark, here... but looks like you might need an older
version of rack installed?  The key line might be:

*can't activate rack-1.1.0, already activated rack-1.1.2*



On Tue, Sep 13, 2011 at 8:33 AM, Galed Friedmann
wrote:

> Hi all,
> I'm trying to install Puppet Dashboard 1.2.0 and having some troubles, I'm
> aware that it's probably something wrong with my ruby/rails environment but
> I really can't seem to figure out why this happens..
>
> My environment is:
> ruby 1.8.7
> rake 0.9.2
> gem 1.8.10
>
> When I try to create the DB schema using the rake command I get alot of
> deprecated errors, which is weird because I meet the requirements that are
> specified in the Puppet docs..
> This is what I get when I try to run the command:
>
> root@master:~/puppet-dashboard-1.2.0[0]# rake RAILS_ENV=production
> db:migrate --trace
> NOTE: Gem.source_index is deprecated, use Specification. It will be removed
> on or after 2011-11-01.
> Gem.source_index called from
> /root/puppet-dashboard-1.2.0/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21.
> NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It
> will be removed on or after 2011-11-01.
> Gem::SourceIndex#initialize called from
> /root/puppet-dashboard-1.2.0/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on or after 2011-11-01.
> Gem::SourceIndex#add_spec called from
> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
> It will be removed on

Re: [Puppet Users] small problem with init script on RHEL6

[Russell Van Tassell]

I've seen a few conflicts between RPM and Source installations relating to
path ... on an Ubuntu server, for example, the binaries landing in /usr/bin
rather than /usr/sbin. Really gets frustrating when distro / repository
maintainers move everything around "to suit their distro" -- it seems like
it's just asking for bugs creep in...

Russell


On Wed, Sep 7, 2011 at 11:32 AM, Jim N  wrote:

>
> I was getting this when starting puppetmasterd (puppet-
> server-0.25.5-1.el6.noarch RPM install):
>
> $ sudo /etc/init.d/puppetmaster start
> Starting puppetmaster: Could not run: Could not create PID file: /var/
> lib/puppet/run/puppetmasterd.pid
>
>
> This change in the init script fixed the problem:
>
> #pidfile=/var/run/puppet/puppetmasterd.pid
> pidfile=/var/lib/puppet/run/puppetmasterd.pid
>
> Is that a bug worth reporting?
>
> Regards,
> Jim
>
> --
> 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 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-users@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] Updating /etc/puppet ?

[Russell Van Tassell]

I'm currently in the same position, and the solution I've proposed (and am
currently working on) involves using a central repository (likely git). The
puppet client (running on the master) simply checks the current master
branch on the remote repository -- if the revisions are not the same, it
just pulls a new copy.

While I've not implemented this, yet ... I'm guessing it should work. Anyone
have any better ideas -- perhaps a check-in hook to trigger at export?

Regards,
Russell


On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang
wrote:

> I have a real-world, best practices, procedural question.
>
> How do you manage the he puppet master, under /etc/puppet, where multiple
> people may be editing files? The /etc/puppet directory is a working copy,
> and each user has read access to files created by other users. However, if
> one person adds a module directory to svn, the lock files that are created
> by svn are owned by that person, and the next person that comes along can't
> do svn updates etc. Similarly I can't write to files created by a different
> user.
>
> Yes, sure, the 'right way' to do this may be to have all the files owned by
> the puppet user, and users don't edit files directly in /etc/puppet, and a
> script is responsible for performing the svn update, but we're not there
> yet.
>
> Ideas?
>
> 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-users@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-users@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] Bind9 & Ubuntu Lucid

[Russell Van Tassell]

Just a couple odd questions... does the status return 0 or 1 when bind is
running? If the process table is used, would you need a "name" parameter to
differentiate the name versus the process name? And, what version of puppet?
You might need a "hasstatus" in there, as well?

Ref: http://docs.puppetlabs.com/references/stable/type.html#service



On Wed, Aug 31, 2011 at 1:43 PM, Craig White  wrote:

> Seems that every cycle, puppet thinks that bind9 service is stopped and
> wants to restart...
>
> info: Applying configuration version '1314822598'
> notice: /Stage[main]/Bind::Service/Service[bind9]/ensure: ensure changed
> 'stopped' to 'running'
> notice: Finished catalog run in 3.70 seconds
>
> But it's running and from the logs, puppet doesn't appear to have any
> impact at all (bind9 was running, continues to run and is not restarted by
> the puppet cycle).
>
> # /etc/init.d/bind9 status
>  * bind9 is running
>
> # update-rc.d -n bind9 defaults
>  System start/stop links for /etc/init.d/bind9 already exist.
>
> # ps aux | grep `cat /var/run/named/named.pid`|grep -v grep
> bind 21856  0.0  0.2 326644 39664 ?Ssl  Aug26   0:17
> /usr/sbin/named -u bind
>
> Extremely simple class...
> class bind::service {
>  service { "bind9":
>ensure => running,
>require => Class["bind::install"],
>  }
> }
>
> ???
>
> --
> Craig White ~
> craig.wh...@ttiltd.com
> 1.800.869.6908 ~~
> www.ttiassessments.com
>
> Need help communicating between generations at work to achieve your desired
> success? Let us help!
>
> --
> 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 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-users@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.