[Puppet Users] Adding basic user accounts via Puppet to Linux systems (minor problem)
We have a need to have the same login accounts exist on several old/legacy
systems internally (older systems, won't be connected to LDAP for a variety
of reasons). Reading around, it seemed like a simple task to do, using the
virtual users and realize functions:
@user { username:
require = Group['staff'],
ensure = present,
uid = ,
gid = 90,
password= '$1$OMITTED.',
groups = wheel,
shell = '/bin/bash',
home= '/home/username',
managehome = true,
}
file { /home/username:
ensure = directory,
recurse = false,
purge = false,
owner = 6332,
group = 90,
require = User['username'],
}
# Realize users
Group | title == staff | - User | title == username |
It works for 4 out of 5 users; the other, puppet doesn't transfer the
password into the shadow file. I've pored over and there are no typos.
The hash is the correct length. Instead, the shadow password for this
user ends up being !!. I remove the user from passwd, shadow and the
homeir and this still happens, regardless. The hash ends in a / (slash)
and I wonder if that might be tripping Puppet up. That's the only thing I
can think of.
Also, if you happen to change the password field, that doesn't get updated
forward, which is not the behavior I expected.
Thanks.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f9f9504b-757f-4024-807c-1f76d47c7eef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet and VMWare (API)
I believe this question is different from others I've seen posted (correct me if I've missed something!). We are looking to automate the creation of VM images, for our growing environment (development, test and production) -- while we're still debating internally about config management options, we have been using Puppet (open source) for our older environment (PE is also under consideration). One of the catches is that VMware provides and API and CLI tools that allow you to query the ESX host (to the extent, I don't yet know) -- such as resources available etc.We would want to do that prior to provisioning a VM, since we have vSphere and several ESX that are managed therein. The internal desire is to have this process as fully-automated from the CLI as possible. I personally would give up some automation for features, but I digress (I'm in the minority, it seems). Can anyone comment on this. There are several tools out there, most which integrate with Puppet or other config management tools, but I don't know which (if any) have the ability beyond basic provisioning to speak/query to the ESX host such as what is provided by VMware (CLI, API/SOAP). It's really a factor of many ways to skin the cat -- finding which one works for us. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a1cdc7c7-47bd-40cb-b656-4872b6312a55%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet 3.4.2 client hangs
I'm experiencing an odd problem with one of my Puppet clients. These systems are identical in configuration, but this one hangs with: puppet agent: applying configurat and I see a yum process. I checked that yum can operate on its own (it does) and there's no other process locking. There's nothing logged in /var/log/puppet (or messages). I'm not sure what to make of it - the other two systems in this trio work fine. This one is just stuck. Could it be something in /var/lib/puppet that is messed up? Thanks, Forrest -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/374b7736-42f1-4e34-ade9-33f16a78724a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Migrating from Puppet open-source to Puppet Enterprise
Thanks, Jason. On a related note, we have maybe 50 +/- hosts -- and though we do use VMWare, I am not sure we really need separate hosts for all of the Roles. For example, the master will be on real-iron, and the PuppetDB will be (for now) virtual. But another role for Console seems like overkill. I don't expect our environment to get substantially large, but it could happen. It seems that once you make a decision on this during the installation, it's going to be very difficult/tedious to try and change it later on. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b7e208f8-12aa-4789-82b7-8339b8fd4f8c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Migrating from Puppet open-source to Puppet Enterprise
Thanks, Jason. I may toss the DB into a separate VM (the Master is on a real-iron system) just to be safe. As for the other roles, I think most of them can live happily on the Master with our smaller infrastructure. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e8e8f9e7-6954-4e04-bf60-bfd9c3d86161%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Migrating from Puppet open-source to Puppet Enterprise
We have perhaps 40 to 50 systems, give or take, that are mostly under Puppet management (not all). After having spent some time doing my own thing with open-source, I'm looking into migrating to PE. One question I have is relative to initial deployment -- if I decide to keep PuppetDB on the same server as Master, can I later migrate that role off onto another host?I don't believe we have enough traffic yet to justify breaking this all down (yet) -- and this will greatly simplify things. I also have the daunting task of re-writing all my individual manifests into proper modules :-) Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/672ddcd1-19e4-4641-a27e-b5972e4c864d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Using file and mount more efficiently
Thanks for the reference, John. We need to ensure that these remote mounts are owned/grouped by specific UID/GID -- hence why I had ownership involved there. We could do this via UID/GID only (not name) if that works better? I don't understand how apply that ownership to /home/201301 would affect / or /home. Then, Puppet would need to check that it's present, has the correct permissions and owership, and ensure it's mounted -- or, in the case of aged data, not mounted and not present. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Using file and mount more efficiently
If Puppet were to manage /home/something, an NFS mount, and ensure it's
mounted... it would automatically look to see if both /home and / were also
mounted?
In most cases, on our older systems, /home is actually just on / -- a full
partition that sits on a raid5 layer. So, at best, Puppet would just get
a standard error that / and /home are already present and mounted.
What I'm concerned about is:
- Ensuring the directories are present, with correct permissions and
ownership
- Ensuring that the NFS mount is active and available (possibly send out
an error vis syslog if not)
- NOT causing some bizarre cascade of mount issues by Puppet repeatedly
attempting to fix something it cannot, in the case of an error that
requires manual intervention.
Our environment is growing substantially, to the point where manually
editing fstab is becoming a real PITA, and also creates an environment for
inconsistencies (and minor typos). So I really need Puppet to manage
those mounts.
I'm not sure I would need automounter for these.
Thanks!
On Friday, September 20, 2013 9:30:35 AM UTC-4, jcbollinger wrote:
On Thursday, September 19, 2013 1:43:07 PM UTC-5, Forrie wrote:
This is something I've been concerned about -- and how to properly
approach this.
For example, we can use Puppet to ensure that the directories (mount
points) exist and that the entries are present in /etc/fstab -- but I grow
very concerned about automating the NFS-mount part of this.
I don't think we'd want to use autofs, as the namespace isn't visible
unless you cd directly into it. We nixed this idea with /home, for
example.
A nitpick: you don't specifically have to cd into an automounted
filesystem to get it mounted; any access at all to the mount point itself
or any child path will do ('ls', fopen(3), I/O redirection, etc.). A child
path works to get the filesystem mounted even if it doesn't actually
correspond to a real file.
In a few places I use symlinks to automounted directories. The symlinks
provide visibility in the expected location, but I get all the goodness of
automounting (however much that may or may not be).
What would be the safest ideal way to approach this?
It's not clear what exactly you hope to achieve. Is it different from
what declaring a Mount with ensure = 'present' will do (which is to ensure
the fs is listed in fstab without managing whether it is mounted)?
You cannot get around the fact that it is impossible to see or touch the
mount point directory underneath a mounted filesystem. Any access to the
mount point path refers to the root of the mounted filesystem instead.
That is a matter of fundamental Unix architecture, quite outside Puppet's
scope.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Using file and mount more efficiently
I've been playing around with this code and have encountered several
errors. As noted below, there is going to be an issue with /home;
however, I thought I could get around that by declaring that /first/, which
won't work -- as it complains about duplicate declarations of /home.
class nfs_mounts_prod {
define nfs_mounts {
$server = ourserver.com
$options =
tcp,rw,hard,intr,vers=3,tcp,rsize=32768,wsize=32768,bg
# These needed to be defined here, it would not work
outside of the class definition
$prod_mounts = [
'201301',
'201301pod',
]
file { /home:
ensure = directory,
owner = root,
group = root,
mode = 0755,
}
file { /home/${name}:
ensure = directory,
owner = 16326,
group = 90,
mode = 0755,
require = File[/home],
} # file
mount { /home/${name}:
device = ${server}:/export/prod/${name},
atboot = yes,
fstype = nfs,
options = ${options},
name = /home/${name},
ensure = mounted,
remounts = true,
pass = 0,
require = File[/home/${name}],
} # mount
} # nfs_mounts
nfs_mounts { $prod_mounts: }
} # class nfs_mounts_prod
Can you tell me what's wrong -- or if this is even going to work :-)
Thanks.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet nodes unable to send report to Puppet Master running under Passenger
I ran into similar problems before, which ended up being the permissions of the rack config.ru file -- it needs to be owned and readable by the puppet user -- check that? Mine was in a path like /etc/puppet/rack/puppetmaster/config.ru. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Using file and mount more efficiently
This is something I've been concerned about -- and how to properly approach this. For example, we can use Puppet to ensure that the directories (mount points) exist and that the entries are present in /etc/fstab -- but I grow very concerned about automating the NFS-mount part of this. I don't think we'd want to use autofs, as the namespace isn't visible unless you cd directly into it. We nixed this idea with /home, for example. What would be the safest ideal way to approach this? Thanks! On Sunday, August 25, 2013 2:57:24 AM UTC-4, jcbollinger wrote: On Sunday, August 25, 2013 1:54:09 AM UTC-5, jcbollinger wrote: Therefore, unless you do something to ensure your FS unmounted before the File is applied, the File will sometimes manage the local directory, but other times manage the remote one. That may be tolerable, [...] I should clarify: it probably is NOT tolerable to unmount and remount the FS during every Puppet run, but it might be tolerable to have Puppet manage the remote filesystem root when that is already mounted. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet and RH chkconfig
I've been trying to follow several threads around Google about Puppet and
it's use (or non-use) of chkconfig on RH Linux.
What prompted me to do this is I noticed that Puppet is, correctly,
repeatedly logging that it is changing a services from ON to OFF. Funny, I
thought I had disabled that with:
service { ip6tables:
enable = false,
ensure = stopped,
}
Which certainly works, but it doesn't disable the service (ie: chkconfig
servicename off) -- it seems like there should be a provider that
correctly integrates with the system chkconfig -- I realize that not all
init scripts honor that, and for that folks can do whatever. This is a
basic functionality of RH Linux that enables, adds, deletes and otherwise
alters the levels of basic services. Seems reasonable that Puppet could
properly interact with it?
We are up to Puppet 3.4.x now. I'm simply asking here as I didn't seem to
find a definitive answer - a lot of code snippets and suggestions, I just
wonder if this is on-tap for improvement or if someone has another, perhaps
clever approach to working with this?
Thanks!
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Using file and mount more efficiently
I have several NFS mounts to manage, on many systems. On each system, I
must ensure that the root directory and path exist and have the correct
permissions beforehand, then ensure they are mounted in Puppet.
For each, I would normally do:
file { /home/directory1:
ensure = directory,
owner = user,
group = group,
mode = 755,
}
mount { /home/directory1:
device = our-thumper.domain.com:/export/directory1,
atboot = yes,
fstype = nfs,
options = tcp,hard,intr,rw,bg,
name = /home/directory1,
ensure = mounted,
remounts = true,
pass = 0,
require = File[/home/directory1],
}
which isn't very efficient when you have a ton of them to mange.
It doesn't appear that Puppet can iterate through an array, but could I do
something like:
file { /home/directory1, /home/directory2, /home/directory3:
but requiring this File will be a problem in the mount pass.
Perhaps a template?
How are others solving this sort of problem? For me, it would be a lot
easier (and more readable) if we could maintain an array at the top of the
rules that contained either the full patch or the basename, then iterate
through them.
_F
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Using file and mount more efficiently
So I would need to define $mounts, presumably as: $mounts = directory1 directory2 directory3 ? Where is $name being defined here. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Passenger with Puppet 3.0, problems running under
I found that. And I was royally peeved, as nowhere in the logs was there any indication there was an issue. The developers of Passenger pointed out that I can set options in the httpd.conf to specify a user and group -- but these products should be logging better data. I literally spent days, going down avenues that I didn't need to go in order to solve this problem, which I randomly found by continuing to Google around. SMH -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Having read through more threads, I ran across an article that pointed out the permissions and ownership of config.ru needed to be owned by puppet:puppet. I changed this and now everything is working. I'm royally annoyed, because nowhere in these logs (either via Puppet or Passenger) was this logged. Seems like a real no-brainer. Bug report. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
The only response to puppet master --debug in the log is : Info: Could not find certificate for 'ourmachine.domain.com' And there is no reference to this system in the master's content under /var/lib/puppet. So it would seem that whatever mechanism that accepts CA requests and creation is borked... ? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Now this is really strange. I removed /var/lib/puppet on the client side and manually did a puppet agent test while doing a command line puppet test on the master and I got: Info: Could not find certificate for 'ourserver.ourdomain.com' Info: Could not find certificate_request for 'ourserver.ourdomain.com' Notice: ourserver.ourdomain.com has a waiting certificate request Notice: Signed certificate request for ourserver.ourdomain.com Notice: Removing file Puppet::SSL::CertificateRequest ourserver.ourdomain.com at '/var/lib/puppet/ssl/ca/requests/ourserver.domain.com.pem' Info: Caching node for ourserver.ourdomain.com Now I am suspicious that there is a problem with rack. My config.ru is based on what is in the latest puppet docs: $0 = master # ARGV --debug ARGV --confdir /etc/puppet ARGV --vardir /var/lib/puppet ARGV --rack require 'puppet/application/master' run Puppet::Application[:master].run And I have no idea if/how/why this would affect Certs. Still going to have to look into this. OR, I can just ditch Passenger and go back to running Puppet by itself. We have 40 hosts, so I don't think I'll miss Passenger, or having to update the *.conf every time there's an update. Thoughts? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
When I updated the config.ru to what's in GIT for puppet, I get a slew of
crap errors that lists the library content for puppet. Here's what is in
GIT now:
# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.
# if puppet is not in your RUBYLIB:
# $LOAD_PATH.unshift('/opt/puppet/lib')
$0 = master
# if you want debugging:
# ARGV --debug
ARGV --rack
# Rack applications typically don't start as root. Set --confdir and
--vardir
# to prevent reading configuration from ~puppet/.puppet/puppet.conf and
writing
# to ~puppet/.puppet
ARGV --confdir /etc/puppet
ARGV --vardir /var/lib/puppet
# NOTE: it's unfortunate that we have to use the CommandLine class
# here to launch the app, but it contains some initialization logic
# (such as triggering the parsing of the config file) that is very
# important. We should do something less nasty here when we've
# gotten our API and settings initialization logic cleaned up.
#
# Also note that the $0 = master line up near the top here is
# the magic that allows the CommandLine class to know that it's
# supposed to be running master.
#
# --cprice 2012-05-22
require 'puppet/util/command_line'
# we're usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Util::CommandLine.new.execute
I think I'm done with Passenger, as it's been nothing but a headache since
I started using it.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Passenger with Puppet 3.0, problems running under
Since upgrading to 3.x I've had some problems running Puppet under
Passenger. I've spent several /days/ debugging this.
The first symptoms included a new agent could not get a CA cert from the
Puppet Master. I checked my configs, permissions, etc.
When I run puppet master in stand-alone mode, it works fine.
I wrote to the Phusion Passenger folks, but they are not familiar with
Puppet and so I'm still trying to figure out what is wrong.
We don't have selinux enabled. sestatus confirms this.
SELinux status: disabled
Of the errors I see in the puppet logs relevant to this:
puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Could not prepare
for execution: Got 3 failure(s) while initializing: Could not set 'file' on
ensure:
Permission denied - /var/log/puppet/masterhttp.log; Could not set 'file'
on ensure: Permission denied - /var/log/puppet/masterhttp.log
puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Wrapped exception:
puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Permission denied
- /var/log/puppet/masterhttp.log; change from absent to file failed: Could
not set
'file' on ensure: Permission denied - /var/log/puppet/masterhttp.log
I tried setting the ownership of the files in that directory to the same
as the apache User, no difference. Again, under regular Puppet there's no
problem.
This is all I have in my config.ru:
$0 = master
ARGV --rack
ARGV --confdir /etc/puppet
ARGV --vardir /var/lib/puppet
require 'puppet/util/command_line'
run Puppet::Util::CommandLine.new.execute
More logs:
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011div
id=site_header
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011ul
class=corporate_identity
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011#011li
class=logoa href=https://www.phusionpassenger.com;
https://www.phusionpassenger.comspanPhusion
Passenger/span/a/li
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011/ul
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011/div
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011div
id=site_body
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011h1
class=error_titleWeb application could not be started/h1
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011div
id=content
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
#011#011#011#011preexit (SystemExit)
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb:wbr518:wbrin
`exitapos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb:wbr518:wbrin
`exit_on_failapos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/application.rb:wbr362:wbrin
`runapos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util/command_line.rb:wbr132:wbrin
`runapos;
It spits out a lot of HTML, CSS... and things I don't think should ever happen,
on the client side.
Looks like it it exiting, mentioning line 518 of
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb, the code of
which
is:
# Now we need to catch **any** other kind of exception, because we may
be calling third-party
# code (e.g. webrick), and we have no idea what they might throw.
rescue Exception = err
## NOTE: when debugging spec failures, these two lines can be very
useful
#puts err.inspect
#puts Puppet::Util.pretty_backtrace(err.backtrace)
Puppet.log_exception(err, Could not #{message}: #{err})
Puppet::Util::Log.force_flushqueue()
exit(code)
end
Anyway, I'm pretty stumped. I am running Puppet 3.x on its own now. We only
have 40 nodes, so it works. But I'd like to figure out what the heck is wrong
with Passenger :-)
Anyone else encounter this problem?
Thanks.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
When I try to connect a new client to this problematic Puppet Master, here's what I see in the log: 10.103.0.3 - - [23/Jul/2013:15:15:27 -0400] GET /production/certificate/ca? HTTP/1.1 200 1915 - - 10.103.0.3 - - [23/Jul/2013:15:15:27 -0400] GET /production/certificate/new-server.domain.com? HTTP/1.1 404 59 - - But in auth.conf, it appears to be correct: path /certificate/ca auth any method find allow * HTTP 404 = not found so, somewhere in this process, the Master is refusing to generate certs. I've checked the directories and permissions and I cannot see a problem there. Likewise, my auth.conf is permissive. It looks like I'm just going to have to start all over again - going through each client manually -- I don't look forward to this at all. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I don't have selinux enabled on this system. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Adding --debug to the config.ru didn't provide any real info -- not sure why, but the client continued to connect and I see this in the log: 10.101.0.10 - - [22/Jul/2013:15:11:15 -0400] GET /production/certificate/machine.ourdomain.com? HTTP/1.1 404 62 - - and nothing is returned. I'm wondering if there is a permissions problem. I can't imagine, as I've never touched it. If I remove all the client SSL certs (backing them up), I presume I would really need to start over again -- that would require going to each client and removing the /var/lib/puppet directory and going through the setup process again. I'm willing to do that, at this point, since I'm not really getting anywhere figuring out what the problem is here. I just want to make sure I do this properly. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Output of puppet config print for SSL : cacert = /var/lib/puppet/ssl/ca/ca_crt.pem cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem cadir = /var/lib/puppet/ssl/ca cakey = /var/lib/puppet/ssl/ca/ca_key.pem capass = /var/lib/puppet/ssl/ca/private/ca.pass caprivatedir = /var/lib/puppet/ssl/ca/private capub = /var/lib/puppet/ssl/ca/ca_pub.pem cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt certdir = /var/lib/puppet/ssl/certs csrdir = /var/lib/puppet/ssl/ca/requests hostcert = /var/lib/puppet/ssl/certs/ourserver.domain.com.pem hostcrl = /var/lib/puppet/ssl/crl.pem hostcsr = /var/lib/puppet/ssl/csr_ourserver.domain.com.pem hostprivkey = /var/lib/puppet/ssl/private_keys/ourserver.domain.com.pem hostpubkey = /var/lib/puppet/ssl/public_keys/ourserver.domain.com.pem ldapssl = false localcacert = /var/lib/puppet/ssl/certs/ca.pem passfile = /var/lib/puppet/ssl/private/password privatedir = /var/lib/puppet/ssl/private privatekeydir = /var/lib/puppet/ssl/private_keys publickeydir = /var/lib/puppet/ssl/public_keys requestdir = /var/lib/puppet/ssl/certificate_requests serial = /var/lib/puppet/ssl/ca/serial signeddir = /var/lib/puppet/ssl/ca/signed ssl_client_ca_auth = ssl_client_header = HTTP_X_CLIENT_DN ssl_client_verify_header = HTTP_X_CLIENT_VERIFY ssl_server_ca_auth = ssldir = /var/lib/puppet/ssl -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Output from puppet config print for SSL configs: cacert = /var/lib/puppet/ssl/ca/ca_crt.pem cacrl = /var/lib/puppet/ssl/ca/ca_crl.pem cadir = /var/lib/puppet/ssl/ca cakey = /var/lib/puppet/ssl/ca/ca_key.pem capass = /var/lib/puppet/ssl/ca/private/ca.pass caprivatedir = /var/lib/puppet/ssl/ca/private capub = /var/lib/puppet/ssl/ca/ca_pub.pem cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt certdir = /var/lib/puppet/ssl/certs csrdir = /var/lib/puppet/ssl/ca/requests hostcert = /var/lib/puppet/ssl/certs/central.de-prod.harvard.edu.pem hostcrl = /var/lib/puppet/ssl/crl.pem hostcsr = /var/lib/puppet/ssl/csr_central.de-prod.harvard.edu.pem hostprivkey = /var/lib/puppet/ssl/private_keys/central.de-prod.harvard.edu.pem hostpubkey = /var/lib/puppet/ssl/public_keys/central.de-prod.harvard.edu.pem ldapssl = false localcacert = /var/lib/puppet/ssl/certs/ca.pem passfile = /var/lib/puppet/ssl/private/password privatedir = /var/lib/puppet/ssl/private privatekeydir = /var/lib/puppet/ssl/private_keys publickeydir = /var/lib/puppet/ssl/public_keys requestdir = /var/lib/puppet/ssl/certificate_requests serial = /var/lib/puppet/ssl/ca/serial signeddir = /var/lib/puppet/ssl/ca/signed ssl_client_ca_auth = ssl_client_header = HTTP_X_CLIENT_DN ssl_client_verify_header = HTTP_X_CLIENT_VERIFY ssl_server_ca_auth = ssldir = /var/lib/puppet/ssl -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I suppose I could just start all over and run through the systems and have them signed. The configurations I have there will still work for the manifests (which I've not converted to proper modules yet). This is probably an option. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I did some poking around and I think I found a better hint as to what may be the issue (feel free to confirm). in /etc/puppet/auth.conf, I had: # allow nodes to request a new certificate path /certificate_request auth any method find, save allow * But the installation has certificate_requests (corrected). Next, I see the actual requests are being cached in: /var/lib/puppet/ssl/ca/requests which I believe is wrong for 3.x... ? There is one outstanding request in there from another machine I accessed a while ago. For sake of clarity, here is the complete content of my auth.conf file, which until recently hasn't been changed since the initial installation: path ~ ^/catalog/([^/]+)$ method find allow $1 path ~ ^/node/([^/]+)$ method find allow $1 path /certificate_revocation_list/ca method find allow * path ~ ^/report/([^/]+)$ method save allow $1 path /file allow * path /certificate/ca auth any method find allow * path /certificate/ auth any method find allow * path /certificate_requests auth any method find, save allow * path / auth any The auth.conf on the client: path /run auth any method save allow our.serverdomain.com path / auth any I'm going to keep looking, but I wonder if I'm close to figuring this out.. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I spent the afternoon re-doing my puppet master, tested it with just 2 new clients and I got the same exact problem. I restored my old /var/lib/puppet so that other agents can work. This is either a bug in Puppet itself or a bizarre configuration issue. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I upgraded our Puppet master to 3.x a while ago, after the file access issues (allow_ip, etc.) were fixed.I didn't actually test connection of a new client until this past week - where the others are running 2.x agent code and working. Here are the gems I have presently: builder (3.2.2) daemon_controller (1.1.4) facter (1.7.2) fastthread (1.0.7) fcgi (0.9.1) ffi (1.9.0) hiera (1.2.1) json (1.8.0) json_pure (1.8.0) libvirt-ruby (1.0.2) passenger (4.0.8) puppet (3.2.3) puppet-lint (0.3.2) puppet-module (0.3.4) rack (1.5.2) rack-protection (1.5.0) rake (10.1.0) rgen (0.6.5) rubygems-update (2.0.5) sinatra (1.4.3) sqlite3 (1.3.7) sqlite3-ruby (1.3.3) stomp (1.2.10) tilt (1.4.1) tzinfo (1.0.1) zonefile (1.04) Now, I could re-install the Puppet 3.x code and see if that resolves the problem. I need to be very careful, as I have many 2.x agents that still require the Puppet master running -- so, if I uninstall the gem, then check to see if the directory and /usr/local/bin copies are removed, reinstall and re-run the master and see what happens. I presume /var/lib/puppet doesn't need to be touched in this case, as it's local data. Yes, of course the master that's running Puppet under Passenger (4.0.8) has been restarted multiple times, in the effort to continue debugging this. Though, I note the post above that mentions adding debug to config.ru - which I'm puzzled by. I suppose I could back-out the Passenger process altogether and run a standard Puppet master and see if the problem persists, also. Thanks! -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Actually, with the improvements to Puppet 3.x, I wonder if it's really necessary to run Puppet under Passenger anymore... we have less than 100 hosts, but that could change. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
Our Master (server) cert has remained intact, last installed on Nov 2 2011. So I don't believe that's the issue. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
[ ... ] Well, that at least narrows it down. The master is not recognizing the client's certificate-signing request, or is refusing to service it. Does the master already have a signed certificate for this client (or at least one bearing the requested certname)? puppet cert list --all should tell you. There are no other certificates for this new system. I checked recursively in the ssl directory, just to be sure. If so, then there are two possibilities: (1) the master signed the current client's current certificate, but is refusing to serve up the signed certificate. This seems unlikely to me, but it cannot be altogether discounted. Not the case. (2) the signed certificate does not correspond to the certificate-signing request currently being presented by the agent (maybe it is an old cert signed for a different machine with the same name), so the master refuses to provide it to the agent. If (2) applies, then you should revoke then remove the old cert via puppet cert, then try again to connect the agent. Alternatively, is there any chance you have multiple copies of the master installed? (Maybe one via RPM and a separate one via gem?) If that's the case, then perhaps the master the agent is talking to is different from the one that comes first in your shell's executable path. That could wreak all sorts of havoc, including misleading you about the relevant certs and CSRs. There is only one master running, one agent: 1149 ?S 1:19 Passenger RackApp: /etc/puppet/rack/puppetmasterd 6946 ?Ss 0:03 /usr/local/bin/ruby /usr/local/bin/puppet agent What strikes me as odd is this is a fresh system that was installed; there's nothing particularly special about it, other than it's CentOS 6.x versus CentOS 5.x which are most of the others. It seems one other person posted here who is experiencing similar problems. What I'm willing to do, as a test case, is configure to new VMs and try a proof-of-bug-or-concept with this. The setup will be simple, one master and one agent; the cert request should be accepted and then manually signed.Though, I think my present configuration is simple enough. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I'm seeing this error in the logs: Jul 17 16:37:17 server puppet-agent[17835]: (/File[/var/lib/puppet/lib]) Could not evaluate: Could not retrieve information from environment production source(s) puppet:/server.ourdomain.com/plugins But I don't believe this is connected to the aforementioned problem. This was a 2.x system upgraded to 3.x. We went through the painful allow vs allow_ip issue, and everything seems to be working. I did a diff of the GIT puppet repository conf/auth.conf and ours is identical. The only difference we have presently (until I rewrite a bunch of stuff) is in fileserver.conf: [files] path/etc/puppet/files # allow * allow_ip10.101.0.0/24 allow_ip10.103.0.0/24 We have a bunch of stuff we replicate from that location; again, it seems to be working fine for the older clients. I also verified that the output of puppet master --configprint=certname indeed matches the servername variable in our puppet.conf file(s). -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I still say the problem is more likely with the master than with the agent. My working hypothesis is that when you upgraded the master to v3.2 you broke its certificate-signing functionality. Supposing that the master's CA certificate was carried over during the upgrade, clients that already have certificates don't need new certs, so they continue to work. (And if the CA cert had not been carried over then all existing clients would have needed new certs.) New clients do need signed certs before they can retrieve catalogs, however, so the clients you are trying to deploy now do not work. By this logic, no new client deployment will work against this master, whether it's Puppet3/Cent6, Puppet2/Cent5, or even Puppet3/Cent5. It is therefore irrelevant how similar your new client systems are to the ones already in operation. Curious, how could I break the CA certificate-signing functionality by upgrading? Wouldn't that be a bug in the upgrade process? I can install a fresh version of Puppet and see if that works - but, I have too many nodes and thus I need to retain the current certificates that are signed. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
I do not have separate Puppet installs. At the moment, it's been installed via the Gem, so the master and agent are coming from the same code, running on the original host (it was not rebuilt). It is running under Passenger/Apache, presently. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate
We are not configured to auto-sign certificates. Clearly, the client is making a connection to the master: 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - - 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - - 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - - Correct, our Master is upgraded to the latest Puppet 3.2.3, as is this particular agent. I've tried starting clean/fresh on the agent (removing /var/lib/puppet) and that has no effect. The older clients are working just fine. puppet cert list, continues to not see the inbound request from this particular agent. our auth.conf certificate rules are fairly standard: # allow access to the CA certificate; unauthenticated nodes need this # in order to validate the puppet master's certificate path /certificate/ca auth any method find allow * # allow nodes to retrieve the certificate they requested earlier path /certificate/ auth any method find allow * # allow nodes to request a new certificate path /certificate_request auth any method find, save allow * Unless something changed between versions that I missed, I believe this should be working.I even hard-coded the servername in the puppet.conf, which has no effect on this agent. The logs above suggest it's looking for the actual certificate, but I don't see the request in the puppet cert list queue. Very puzzled. Thanks. [ .. ] And your master is configured to autosign certificates? Because that's not the default, and you didn't say anything about signing them manually. You can check whether there are any outstanding certificate requests by running puppet cert list on the master. In fact, did you recently upgrade your master to its current version? As in, since the working clients were issued their certs? If so, then perhaps the upgrade somehow reset the master's certificate management configuration to the default of not autosigning. I've Googled around for this error, but I don't see a solution to my issue -- I wonder if I'm missing a ruby gem, or if there is generally something wrong with running this on CentOS 6 (that would be odd). I have tried completely removing /var/lib/puppet on the agent and starting over, that has no effect. The puppet.conf I'm using on all my systems: [main] server = my-server.name.com vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl [agent] classfile = $vardir/classes.txt localconfig = $vardir/localconfig syslogfacility = local4 report = true listen = true Am I missing something? Granted, the older clients are running 2.7.x, so perhaps I've missed something in the upgrade docs and I need to add to the *.conf file. The master server is running Puppet 3.2.2 under Passenger 4.0.8, all the other clients are connecting just fine. Iptables is not a factor here, either. I am disinclined to think that the problem is actually at the agent. That the other agents are working is not a counterindication, for the place where the process seems to be failing is outside the path that is ordinarily traversed in servicing catalog requests. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] 3.2.2 on CentOS 6.3, and Did not receive certificate
The CentOS systems I built are 3.2.2 and the master is 3.2.2. the older clients are working fine - they are being upgraded, once I solve this issue. On Thursday, July 11, 2013 2:44:58 PM UTC-4, Dan wrote: You should be running puppet version 2 clients with puppetmaster version 2. You should be running puppet version 3 clients with puppetmaster version 3. On Thu, Jul 11, 2013 at 11:41 AM, Forrie for...@gmail.com javascript:wrote: I'm having a perplexing problem with Puppet 3.2.2 (agent) on CentOS 6.3.There are two systems, recently built, that exhibit the same problem. I'm using the same, very basic and simple config I have on all of my systems (most of which are CentOS 5). This system has its own ruby and puppet installation (gem), which is the only real difference. Basically, I can't get the master to generate a certificate. I can telnet to the puppet inbound port, no problem. here's what I see: [ puppet master log ] 10.101.0.10 - - [11/Jul/2013:14:30:50 -0400] GET /production/certificate/ de-prod-archive.de-prod.harvard.edu? HTTP/1.1 404 62 - - 10.101.0.10 - - [11/Jul/2013:14:30:50 -0400] GET /production/certificate/ de-prod-archive.de-prod.harvard.edu? HTTP/1.1 404 62 - - [ puppet client log / debug, no-daemonize ] Debug: Finishing transaction 69955790206320 Info: Creating a new SSL key for de-prod-archive.de-prod.harvard.edu Info: Caching certificate for ca Info: Caching certificate_request for de-prod-archive.de-prod.harvard.edu Debug: Using cached certificate for ca Debug: Using cached certificate for ca Debug: Using cached certificate for ca Notice: Did not receive certificate I've Googled around for this error, but I don't see a solution to my issue -- I wonder if I'm missing a ruby gem, or if there is generally something wrong with running this on CentOS 6 (that would be odd). I have tried completely removing /var/lib/puppet on the agent and starting over, that has no effect. The puppet.conf I'm using on all my systems: [main] server = my-server.name.com vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl [agent] classfile = $vardir/classes.txt localconfig = $vardir/localconfig syslogfacility = local4 report = true listen = true Am I missing something? Granted, the older clients are running 2.7.x, so perhaps I've missed something in the upgrade docs and I need to add to the *.conf file. The master server is running Puppet 3.2.2 under Passenger 4.0.8, all the other clients are connecting just fine. Iptables is not a factor here, either. Thanks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com javascript:. To post to this group, send email to puppet...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I see the ChangeLog in 3.0.2 and this bug is still not addressed? Is there a technical problem that is not yet resolved, or is this just a matter of priority and time. -- 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/-/aoZ7BtDcqwwJ. 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] Web interface to Facter information, system config reporting?
Thanks for the pointers, I will have a look at it. -- 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/-/pseaLhp7xtwJ. 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] Web interface to Facter information, system config reporting?
In our department, we recently bought an install of HP's SIM agent -- it's some hacky configuration reporting and management platform that also facilitates firmware updates, etc. I don't care for it. For one, it requires root logins, but it also has agents that report -- it also may have the ability to change the system. My boss is looking for information that is presented in a GUI and easily reportable. I'm thinking Facter is a good candidate here - we can tell it what version of software (SSH, etc), OS, etc. But, it's all command-line. I'm wondering if there is (or if someone is working on) a web-based GUI that can report these statistics (we don't need the overhead of something like puppet-dashboard). And for misc things, we can always write custom facts. Of course, this would only apply to systems that are running puppet. We have others that are not. I've seen some other hacks out there that do different types of reporting - if there's some better approach (open source), that would be great to know about. Thanks. -- 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/-/7L0fdmA0VNIJ. 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] Re: Issue with service = disabled and stopped
Thanks, I went ahead and added an exit 1 at the bottom of each of these scripts to shut it up. At least, in the case of the cups- config-daemon, it's been deprecated so I can just remove that check. HIDD is another issue. Most of the init.d scripts use RETVAL=$? after the status) query -- so that's hooked in somewhere to the functions perhaps and that it doesn't work properly with HIDD is really a bug, per se. -- 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] Re: Issue with service = disabled and stopped
Thanks for the explanation, I appreciate it. These services are provided by Redhat as are the init scripts, which report: # /etc/init.d/cups-config-daemon status cups-config-daemon is obsolete # /etc/init.d/hidd status hidd is stopped I can see where the first one is unexpected to Puppet. I am running: # puppet --version 2.7.19 -- 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] Issue with service = disabled and stopped
I have a simple manifest that I'm using to keep unwanted services from
running on an array of Linux systems. On my test host, I see these
two services repeatedly come up in the puppet.log, even tho they are
not running and are chkconfig set to off:
service { cups:
enable = false,
ensure = stopped,
}
service { cups-config-daemon:
enable = false,
ensure = stopped,
}
The log:
Nov 16 19:11:39 test-fms puppet-agent[6530]: (/Stage[main]/Disabled-
services/Service[cups-config-daemon]/ensure) ensure changed 'running'
to 'stopped'
Nov 16 19:11:40 test-fms puppet-agent[6530]: (/Stage[main]/Disabled-
services/Service[hidd]/ensure) ensure changed 'running' to 'stopped'
verify in chkconfig:
cups-config-daemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off
hidd0:off 1:off 2:off 3:off 4:off 5:off 6:off
This shows up every time puppet agent runs for this host. Why would
this be happening?
This is using puppet 2.7.19 and the latest ruby 1.8.7.
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.
[Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Ugh, thank you for taking the time to point all of that out. It took me a little while, but I think it's working now in test mode. Question, so for every directory underneath /etc/puppet/files, I need a separate stanza in fileserver.conf, so a new directory called /etc/puppet/files/blah would be in fileserver.conf [blah] path /etc/puppet/files/blah allow * AND in auth.conf path ~ ^/file_(metadata|content)/blah/ auth yes allow /^(.+\.)?harvard.edu$/ allow_ip 127.0.0.0/8 allow_ip 10.0.0.0/8 Then my [etc] path ~ ^/file_(metadata|content)/etc/ auth yes allow /^(.+\.)?harvard.edu$/ allow_ip 127.0.0.0/8 allow_ip 10.0.0.0/8 However, is /this/ necessary, too? path ~ ^/file_(metadata|content)/ auth yes allow /^(.+\.)?harvard.edu$/ allow_ip 127.0.0.0/8 allow_ip 10.0.0.0/8 Thanks! -- 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/-/DwROgTImZekJ. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
The files we have that go out are under /etc/puppet/files. So, the ntp.conf exists under /etc/puppet/files/etc/ntp.conf -- there are also other structures under /etc/puppet/files that we refer to. I would presume a more efficient way to refer to this is any file under /etc/puppet/files. This is starting to get confusing :-) Yeah, the example.com was a typo on my part. I do have our own domain there. Here's the relevant part of that config: path ~ ^/file_(metadata|content)/files/etc/ path /file auth yes allow /^(.+\.)?ourdomain.com$/ allow_ip 10.0.0.0/8 which still generates errors: # puppet agent --test Ignoring --listen on onetime run Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 403 on SERVER: Forbidden request: stage1.ourdomain.com(127.0.0.1) access to /node/stage1.ourdomain.com [find] authenticated at :101 Info: Retrieving plugin Info: Caching catalog for stage1.ourdomain.com Info: Applying configuration version '1352241407' Error: /Stage[main]/Ntp-client/File[/etc/ntp.conf]: Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf Could not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf /Stage[main]/Ntp-client/Service[ntpd]: Dependency File[/etc/ntp.conf] has failures: true Warning: /Stage[main]/Ntp-client/Service[ntpd]: Skipping because of failed dependencies Finished catalog run in 1.45 seconds I think I found another bug. I added the localhost with allow_ip 127/8 which is a valid CIDR notation; I had to change it to allow_ip 127.0.0.0/8 but it still failed anyway: Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 403 on SERVER: Forbidden request: stage1.ourdomain.com(127.0.0.1) access to /node/stage1.ourdomain.com [find] authenticated at :102 Do I also need to include allow * in the directive? Seems that would take precedence over allow_ip. Any word on when a fixed release is going to come out :-) Thanks On Wednesday, October 31, 2012 1:03:36 PM UTC-4, Nick Fagerlund wrote: Hi, Forrie, I see a handful of problems here: * First, you can't comment out the path /file allow * rule in auth.conf, because Puppet actually uses that for pluginsync and for files in modules! What you have to do is have BOTH the new rule I gave you AND the old one, but make sure the new one comes FIRST so that it can prevent the broader rule from being applied to the specific mount point you're trying to protect. * Second, you copied my example path ~ ^/file_(metadata|content)/files/ URL, but it looks like the actual mount point you're using is named [etc] in fileserver.conf. That means you should change the rule to path ~ ^/file_(metadata|content)/etc/. You can see in the logs that the rule isn't matching the requests, both because the URL is wrong ( /file_metadata/etc/ntp.conf, whereas the rule is expecting /file_metadata/files/ntp.conf) and because it's citing line 100 or 102 of auth.conf (meaning it skipped the rule). * The IP address COULD be a problem, since you're connecting to the master from 127.0.0.1. Right now, it looks like you have a literal example.com in auth.conf and your real domain elsewhere, which would be a problem, but you probably just missed that when editing out your site-specific details. IF there's still an example.com in your auth.conf, and I realize there's probably not, you should replace it with your real domain. Try fixing those and see where it gets you. Good luck! -- 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/-/zSzrbO-yk8UJ. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Wednesday, October 24, 2012 7:44:26 PM UTC-4, Nick Fagerlund wrote:
HMMM, this actually sounds like you've got a slightly larger problem,
since can't get its own node object or its plugins. Any chance we could get
a look at your whole auth.conf?
On Wednesday, October 24, 2012 3:41:32 PM UTC-7, Forrie wrote:
No, I didn't leave *example.com* in my config - I put our own domain in
there... just FYI ;-)
auth.conf is below.
First, we have some simple classes that we use to manage files and packages
that do not need to be in a module. For example,
/etc/puppet/files/etc/ntp.conf is a file I distribute to all our internal
systems and I use this very simple recipe to manage them, which works fine
under 2.7:
[ ntp-client.pp ]
class ntp-client {
file { /etc/ntp.conf:
owner = root,
group = root,
mode= 644,
source = puppet:///etc/ntp.conf,
require = [ Package[ntp] ],
notify = Service[ntpd],
}
package { ntp:
ensure = latest,
}
service { ntpd:
ensure = running,
hasrestart = true,
subscribe = File[/etc/ntp.conf],
}
} # ntp-client
From what I read in the docs, this /should/ work. But it doesn't. I
shouldn't have to create a module path in order for this recipe to work (as
I've seen suggested, or I've misunderstood).
Here is the auth.conf file:
[ auth.conf ]
# This is an example auth.conf file, it mimics the puppetmasterd defaults
#
# The ACL are checked in order of appearance in this file.
#
# Supported syntax:
# This file supports two different syntax depending on how
# you want to express the ACL.
#
# Path syntax (the one used below):
# -
# path /path/to/resource
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The path is matched as a prefix. That is /file match at
# the same time /file_metadat and /file_content.
#
# Regex syntax:
# -
# This one is differenciated from the path one by a '~'
#
# path ~ regex
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|ip]
#
# The regex syntax is the same as ruby ones.
#
# Ex:
# path ~ .pp$
# will match every resource ending in .pp (manifests files for instance)
#
# path ~ ^/path/to/resource
# is essentially equivalent to path /path/to/resource
#
# environment:: restrict an ACL to a specific set of environments
# method:: restrict an ACL to a specific set of methods
# auth:: restrict an ACL to an authenticated or unauthenticated request
# the default when unspecified is to restrict the ACL to authenticated
requests
# (ie exactly as if auth yes was present).
#
### Authenticated ACL - those applies only when the client
### has a valid certificate and is thus authenticated
# allow nodes to retrieve their own catalog (ie their configuration)
path ~ ^/catalog/([^/]+)$
method find
allow $1
# allow all nodes to access the certificates services
path /certificate_revocation_list/ca
method find
allow *
# allow all nodes to store their reports
path /report
method save
allow *
# inconditionnally allow access to all files services
# which means in practice that fileserver.conf will
# still be used
# path /file
# allow *
# allow_ip 10.101.0.0/24
# allow_ip 10.103.0.0/24
# Note that nothing here works, regardless of the CIDR
path ~ ^/file_(metadata|content)/files/
auth yes
allow /^(.+\.)?example.com$/
allow_ip 10.0.0.0/8
### Unauthenticated ACL, for clients for which the current master doesn't
### have a valid certificate
# allow access to the master CA
path /certificate/ca
auth no
method find
allow *
path /certificate/
auth no
method find
allow *
path /certificate_request
auth no
method find, save
allow *
# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
# allow *
auth any
Here are some of the errors I'm seeing today. I do not have any other
modules or classes defined here, just the ntp-client.pp on the staging
system:
Oct 30 17:50:38 stage1 puppet-agent[3421]: catalog supports formats:
b64_zlib_yaml dot pson raw yaml; using pson
Oct 30 17:50:38 stage1 puppet-agent[3421]: Caching catalog for
stage1.mydomain.com
Oct 30 17:50:38 stage1 puppet-agent[3421]: Creating default schedules
Oct 30 17:50:38 stage1 puppet-agent[3421]: Loaded state in 0.00 seconds
Oct 30 17:50:38 stage1 puppet-agent[3421]: Applying configuration version
'1351630198'
Oct 30 17:50:38 stage1 puppet-agent[3421]:
(/Stage[main]/Ntp-client/Service[ntpd]/subscribe) subscribes to
File[/etc/ntp.conf]
Oct 30 17:50:38 stage1 puppet-agent[3421]:
(/Stage[main]/Ntp-client/File[/etc/ntp.conf]/require) requires Package[ntp]
Oct 30 17:50:38 stage1 puppet-agent[3421]:
(/Stage[main]/Ntp-client/File[/etc/ntp.conf]/notify) subscribes to
Service[ntpd]
Oct 30
Re: [Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I applied the fixes to my test/staging config and it's not very happy. I think I'll just wait for the official fix to be out before I move forward with 3.x. :-) For giggles, here's the log: # puppet agent --test Ignoring --listen on onetime run Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :102 Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [search] authenticated at :102 Error: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Could not retrieve file metadata for puppet://stage1.myserver.com/plugins: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/plugins [find] authenticated at :102 Info: Caching catalog for stage1.myserver.com Info: Applying configuration version '1351113815' Error: /Stage[main]/Ntp-client/File[/etc/ntp.conf]: Could not evaluate: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 Could not retrieve file metadata for puppet:///etc/ntp.conf: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /file_metadata/etc/ntp.conf [find] authenticated at :102 /Stage[main]/Ntp-client/Service[ntpd]: Dependency File[/etc/ntp.conf] has failures: true Warning: /Stage[main]/Ntp-client/Service[ntpd]: Skipping because of failed dependencies Everything under /var/lib/puppet was created by the puppetmaster -- /var/lib/puppet/lib is owned by root:root as it is on my /working/ puppet master. [ fileserver.conf ] [files] path /etc/puppet/files allow * [ auth.conf ] path ~ ^/file_(metadata|content)/files/ auth yes allow /^(.+\.)?example.com$/ allow_ip 10.101.0.0/24 allow_ip 10.103.0.0/24 allow_ip 127.0.0.0/24 I tried the last one, 127/24, to see if the issue was with the client connecting locally; made no difference. Everything else in auth.conf is allow * We have a set of files in /etc/puppet/files/etc/blah-blah that are copied over to the clients. They are not in a module (don't need to be). I read somewhere that you need to put your files in the modules that belong to them, this doesn't apply here as far as I can tell. In any case... that's all going off on a tangent.I hope the fix will be out soon :-) Thanks. -- 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/-/cx8NwigZpBAJ. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
No, I didn't leave *example.com* in my config - I put our own domain in there... just FYI ;-) -- 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/-/ZLmd7xSH5A4J. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Wow, thank you Nick for taking the time to post that. Much appreciated! I have moved Puppet 3.0.x onto a staging system to test out all the kinks before I upgrade our primary master. So I will test out your suggestions -- otherwise this bug pretty much brings all of our Puppet down and makes it useless. Thank you. -- 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/-/rrH3xQwAMdwJ. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Still no go. I have a bunch of simple class files stored in /etc/puppet/manifests/classes -- not sure how that got designed, but I followed a book or two. It's been working so far, until 3.0. Here is the error when I prepend modules to the statement: Oct 19 14:41:47 stage1 puppet-agent[21124]: Ignoring --listen on onetime run Oct 19 14:41:48 stage1 puppet-master[21126]: Starting Puppet master version 3.0.1 Oct 19 14:41:48 stage1 puppet-master[21155]: Denying access: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :95 Oct 19 14:41:48 stage1 puppet-master[21155]: Forbidden request: stage1.myserver.comu(127.0.0.1) access to /node/stage1.de-prod.harvard.edu [find] authenticated at :95 Oct 19 14:41:48 stage1 puppet-agent[21124]: Unable to fetch my node definition, but the agent run will continue: Oct 19 14:41:48 stage1 puppet-agent[21124]: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :95 Oct 19 14:41:48 stage1 puppet-master[21155]: Error parsing fileserver configuration: wrong number of arguments (3 for 1); using old configuration Oct 19 14:41:51 stage1 puppet-master[21155]: Compiled catalog for stage1.myserver.com in environment production in 1.79 seconds Oct 19 14:41:54 stage1 puppet-agent[21124]: (/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate: Could not retrieve information from environment production source(s) puppet:///modules/etc/ntp.conf Oct 19 14:41:54 stage1 puppet-agent[21124]: (/Stage[main]/Ntp-client/Service[ntpd]) Dependency File[/etc/ntp.conf] has failures: true Oct 19 14:41:54 stage1 puppet-agent[21124]: (/Stage[main]/Ntp-client/Service[ntpd]) Skipping because of failed dependencies Oct 19 14:41:54 stage1 puppet-agent[21124]: Finished catalog run in 1.85 seconds I figured modules wouldn't work as it's not there anyway. So, moving it back to the normal URL, which would refer to the file as puppet:///etc/ntp.conf (removing files as the docs say), I get this: Oct 19 14:45:17 stage1 puppet-agent[21635]: Ignoring --listen on onetime run Oct 19 14:45:18 stage1 puppet-master[21638]: Starting Puppet master version 3.0.1 Oct 19 14:45:18 stage1 puppet-master[21667]: Denying access: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :95 Oct 19 14:45:18 stage1 puppet-master[21667]: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.myserver.com [find] authenticated at :95 Oct 19 14:45:18 stage1 puppet-agent[21635]: Unable to fetch my node definition, but the agent run will continue: Oct 19 14:45:18 stage1 puppet-agent[21635]: Error 403 on SERVER: Forbidden request: stage1.myserver.com(127.0.0.1) access to /node/stage1.de-prod.harvard.edu [find] authenticated at :95 Oct 19 14:45:18 stage1 puppet-master[21667]: Error parsing fileserver configuration: wrong number of arguments (3 for 1); using old configuration Oct 19 14:45:19 stage1 puppet-master[21667]: Compiled catalog for stage1.myserver.com in environment production in 0.69 seconds Oct 19 14:45:22 stage1 puppet-master[21667]: Not authorized to call find on /file_metadata/etc/ntp.conf Oct 19 14:45:22 stage1 puppet-agent[21635]: (/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf Could not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf Oct 19 14:45:22 stage1 puppet-agent[21635]: (/Stage[main]/Ntp-client/Service[ntpd]) Dependency File[/etc/ntp.conf] has failures: true Oct 19 14:45:22 stage1 puppet-agent[21635]: (/Stage[main]/Ntp-client/Service[ntpd]) Skipping because of failed dependencies Oct 19 14:45:22 stage1 puppet-agent[21635]: Finished catalog run in 1.98 seconds So I'm back to square one. From what I've read, there is an error with auth_ip not being recognized in fileserver.conf -- so, fine, why doesn't the older behavior not work? The auth.conf file just has * next to the allow, which should still work. The error message makes no sense to me: Error parsing fileserver configuration: wrong number of arguments (3 for 1) There is only one arg after allow - it doesn't seem to care what I put in there at this point. I'm baffled (and getting really frustrated with this). Thanks. On Friday, October 19, 2012 10:07:10 AM UTC-4, Alex C wrote: I ran into a similar issue when upgrading to 3.0. Make sure your specify 'modules' when loading puppet:// resources that are includes in modules: source = puppet:///modules/etc/ntp.conf, -- 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/-/jWf6ENN3nr4J. To post to this group, send
[Puppet Users] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
To make matters worse, I'm referring to the documentation on puppetlabs.comhttp://docs.puppetlabs.com/guides/file_serving.html that seems outdated for this newer release. So I try all of these combinations and they do not work in fileserver.conf: allow * allow *.subdomain.company.com allow xx.xx.xx.xx (Ip address) Am I missing something here? My auth.conf hasn't changed, it has simple * that should work fine. -- 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/-/8eEaauI30TAJ. 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] Re: Puppet 3.0 upgrade issue
I'm running into a similar problem; however, even the changes to config.ru
don't seem to make a difference. First, here are the GEMs I have
installed:
daemon_controller (1.0.0)
facter (1.6.13)
fastthread (1.0.7)
ffi (1.1.5)
hiera (1.1.0, 1.0.0)
json (1.7.5)
libvirt-ruby (1.0.2)
passenger (3.0.17)
puppet (3.0.1)
puppet-lint (0.3.1)
puppet-module (0.3.4)
rack (1.4.1)
rack-protection (1.2.0)
rake (0.9.2.2)
rubygems-update (1.8.24)
sinatra (1.3.3)
stomp (1.2.6)
tilt (1.3.3)
tzinfo (0.3.33)
I built a staging system to test out Puppet 3.0.1 and Passenger, latest
versions. I have another similar system, running Puppet 2.x with
Passenger which is working fine.
Here is my config.ru (hash comments removed for brevity):
$0 = master
ARGV --rack
ARGV --confdir /etc/puppet
require 'puppet/util/command_line'
run Puppet::Util::CommandLine.new.execute
The file is owned by puppet:puppet as is the Rack directory, which is
/etc/puppet/rack/puppetmasterd/public
My /etc/httpd/conf.d/passenger.conf is simple enough:
LoadModule passenger_module
/usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.17/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.17
PassengerRuby /usr/local/bin/ruby
Listen 8140
VirtualHost *:8140
SSLEngine On
# SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /var/lib/puppet/ssl/certs/stage1.myserver.com.pem
SSLCertificateKeyFile
/var/lib/puppet/ssl/private_keys/stage1.myserver.com.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars
# The following client headers allow the same configuration to work with
Pound.
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
PassengerHighPerformance on
PassengerMaxPoolSize 15
PassengerPoolIdleTime 300
PassengerUseGlobalQueue on
PassengerStatThrottleRate 120
RackAutoDetect On
RailsAutoDetect Off
RackBaseURI /
DocumentRoot /etc/puppet/rack/puppetmasterd/public
Directory /etc/puppet/rack/puppetmasterd/public
Options None
AllowOverride None
Order allow,deny
allow from all
/Directory
/VirtualHost
I've tried this with the AutoDetect of Rails and Rack on|off. What I see
is httpd starts up fine, along with the Passenger processes, but there is
no puppet.
I can run puppet by itself with no trouble, however.
I've been poring over this since yesterday and I honestly can't figure out
what's wrong. Unless it has to do with GEM versions that are not working
correctly?
Before I put this out into production, I want to be sure the steps to get
this working are clearly documented in case it breaks, etc.
Thanks.
--
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/-/xro1t8Kr10gJ.
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 3.0 upgrade issue
Interesting question - I tested this out and it does indeed seem to be the case. Unexpected behavior, however. On Thursday, October 18, 2012 6:02:22 PM UTC-4, Ellison Marks wrote: Is it the case that the application doesn't technically exist until an agent tries to hit the port? -- 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/-/BKqbvuxDKDEJ. 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] Re: Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
I've just built a staging system, to work out the issues I've been having with Puppet 3.x. We now have 3.0.1 installed there. I am again running into this fileserver issue and the same errors. I read through some complaints here and I see mention that auth.conf is only able to use allow_ip. In that file, I have allow * under path /file which should allow everyone. I read that the allow_ip is not yet working for fileserver.conf. My fileserver.conf has allow 192.168.0.0/24 which was working until the upgrade. So, can someone explain to me in plain english how we're supposed to get this working properly now. I read through more notes and I don't see mention of this in upgrading, etc. Perhaps I missed something -- I just want to get it working. If it's an outstanding but that is preventing Puppet from working right now, I would think this would be a high-priority fix :-) Thanks. -- 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/-/wvCuF3fd2H8J. 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 3.0 upgrade issue
Thanks for that pointer... I put that in my config. -- 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/-/oHhOu4PZsb0J. 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 3.0: Not authorized to call find on /file_metadata, more issues?
Jeff, Thanks for the reply. This is the first Puppet distribution that I've upgraded to that required a lot of manual changes. But that comes with the territory :-) What I think would be very useful is to not only include sample *.conf files, init scripts, and such, but also example usage of new features in common scenarios. For example, Eric S. referred to the config file https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf which does state allow_ip in the top portion, but there's no usage example in the content. I sometimes find it easier to grok changes when I see contextual examples :-) That might be a bad example, as it's pretty simple -- but I think you get the gist of what I mean. Thanks again! Forrest -- 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/-/78NYNBHDZ94J. 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 3.0: Not authorized to call find on /file_metadata, more issues?
The ChangeLog and the PR are not clear about this. In fact, the
documentation is vague and doesn't really mention allow_ip at all. This
should be updated and made more clear?
I will give this a try later on, on a test system, and see if that solves
the problem.
Thanks.
On Tuesday, October 2, 2012 1:30:34 AM UTC-4, Matthaus Litteken wrote:
Oh, sorry, you mention that you already found that changelog entry. I
misread that part.
On Mon, Oct 1, 2012 at 10:27 PM, Matthaus Owens
matt...@puppetlabs.comjavascript:
wrote:
In Puppet 3.x, allow directives are limited to hostnames, if you wish
to allow an ip address, the allow_ip directive should be used. This
was in response to CVE-2012-3408
(http://puppetlabs.com/security/cve/cve-2012-3408/).
On Mon, Oct 1, 2012 at 5:48 PM, Forrie for...@gmail.com javascript:
wrote:
I've seen mention of this error in several places, with different
causes.
So before I posted here, I attempted to resolve this on my own.
I corrected the change from puppet:///files to puppet:/// in my
manifests
*.pp files.
No changes were made to the auth.conf file, and I did note in the
ChangeLog
that:
Auth.conf differentiates between names and IPs – There’s a new
allow_ip
keyword in auth.conf if you want to permit IP addresses. (PR991)
But I see no mention of that on the docs page at
http://docs.puppetlabs.com/guides/rest_auth_conf.html.
Our auth.conf is simple, and basically has either allow $1 or allow
*
both which appear to still be valid in 3.0.
Here's an example, a simple example, an ntp.conf file:
class ntp-client {
file { /etc/ntp.conf:
owner = root,
group = root,
mode= 644,
source = puppet:///etc/ntp.conf,
require = [ Package[ntp] ],
notify = Service[ntpd],
}
package { ntp:
ensure = latest,
}
service { ntpd:
ensure = running,
hasrestart = true,
subscribe = File[/etc/ntp.conf],
}
} # ntp-client
The error I'm seeing in the puppet.log, on the client system:
Oct 1 20:02:28 test-fms puppet-agent[11062]: Starting Puppet client
version 2.7.17
Oct 1 20:02:31 test-fms puppet-agent[11062]:
(/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate:
Error 400
on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf
Could
not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on
SERVER:
Not authorized to call find on /file_metadata/etc/ntp.conf at
/etc/puppet/manifests/classes/ntp-client.pp:10
The permissions from /etc/puppet/files are correct:
-rw-r--r--. 1 puppet puppet 446 Mar 31 2011 etc/ntp.conf
The client puppet.conf file doesn't have any custom references other
than
the basics.
[main]
server = ourpuppet.server.com
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
syslogfacility = local4
report = true
listen = true
I ran puppet master in verbose mode and got these diagnostics:
Starting Puppet master version 3.0.0
Info: access[^/catalog/([^/]+)$]: allowing 'method' find
Info: access[^/catalog/([^/]+)$]: allowing $1 access
Info: access[/certificate_revocation_list/ca]: allowing 'method' find
Info: access[/certificate_revocation_list/ca]: allowing * access
Info: access[/report]: allowing 'method' save
Info: access[/report]: allowing * access
Info: access[/file]: allowing * access
Info: access[/certificate/ca]: adding authentication no
Info: access[/certificate/ca]: allowing 'method' find
Info: access[/certificate/ca]: allowing * access
Info: access[/certificate/]: adding authentication no
Info: access[/certificate/]: allowing 'method' find
Info: access[/certificate/]: allowing * access
Info: access[/certificate_request]: adding authentication no
Info: access[/certificate_request]: allowing 'method' find
Info: access[/certificate_request]: allowing 'method' save
Info: access[/certificate_request]: allowing * access
Info: access[/]: adding authentication any
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACL
Info: Inserting default '/status' (auth true) ACL
Warning: Host is missing hostname and/or domain: one-host.ourdomain.com
Compiled catalog for one-host.ourdomain.com in environment production
in
1.16 seconds
Info: mount[files]: allowing 10.101.0.0/24 access
Error: Error parsing fileserver configuration: wrong number of
arguments (3
for 1); using old configuration
Error: Not authorized to call find on /file_metadata/etc/ntp.conf
Error: Not authorized to call find on /file_metadata/etc/sudoers
Error
[Puppet Users] Re: Puppet 3.0 deprecates the kick command
They recommend installing MCollective, which I've not tackled yet -- but it seems like overkill for basic needs that were met by simple puppet kick. There are other options out there like Func, et al. -- 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] Re: Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7
I solved the ruby18_dev dependency. However, when I go to compile, I
get this error:
# gem install puppet
Building native extensions. This could take a while...
ERROR: Error installing puppet:
ERROR: Failed to build gem native extension.
/opt/csw/bin/ruby18 extconf.rb
creating Makefile
make
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
make: *** [generator.o] Error 127
Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/
json-1.7.5 for inspection.
Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/
ext/generator/gem_make.out
Interesting as I haven't used that in a long time and it's not
installed here. This variable is not set anywhere in the environment
that I can tell. Equally, when I manually set CC=/opt/csw/bin/gcc
(and export it) the build does not honor that.
Interestingly, when I do a find I can see this mentioned in the /opt/
csw/lib/ruby structure:
# find . -type f -exec grep SUNWspro {} \;
CONFIG[configure_args] = '--prefix=/opt/csw' '--exec_prefix=/opt/
csw' '--bindir=/opt/csw/bin' '--sbindir=/opt/csw/sbin' '--libexecdir=/
opt/csw/libexec' '--datadir=/opt/csw/share' '--sysconfdir=/opt/csw/
etc' '--sharedstatedir=/opt/csw/share' '--localstatedir=/opt/csw/var'
'--libdir=/opt/csw/lib' '--infodir=/opt/csw/share/info' '--includedir=/
opt/csw/include' '--mandir=/opt/csw/share/man' '--enable-pthread' '--
enable-shared' '--with-tcl-dir=/opt/csw' '--with-tk-dir=/opt/csw' '--
with-dbm-dir=/opt/csw/bdb48' '--with-gdbm-dir=/opt/csw' '--with-iconv-
dir=/opt/csw' '--with-openssl-dir=/opt/csw' '--with-readline-dir=/opt/
csw' '--with-zlib-dir=/opt/csw' '--program-suffix=18' 'CC=/opt/
SUNWspro/bin/cc' 'CFLAGS=-xO3 -m32 -xarch=386' 'LDFLAGS=-L/opt/csw/
lib' 'CPPFLAGS=-I/opt/csw/include'
CONFIG[CPP] = /opt/SUNWspro/bin/cc -E
CONFIG[CC] = /opt/SUNWspro/bin/cc
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
CC = /opt/SUNWspro/bin/cc
We have solstudio2.2 installed -- so I put a symlink in /opt pointing
SUNWspro - solstudio2.2 and it seems happy.
I'm just putting this out here in case someone else gets bitten by
it :-)
--
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] More Puppet 3.0 upgrade issues: rest.rb and runinterval ?
The last issue I had was missing init.d scripts and the removed puppetmaster in favor of puppet master. I upgraded back to 3.0, uninstalled the old versions to avoid conflict. Puppet master starts, but the client is choking on this error: Oct 1 16:55:46 central puppet-agent[26980]: Could not autoload puppet/indirector/certificate/rest: Invalid duration format '900 # 15 mins' for parameter: runinterval Oct 1 16:55:46 central puppet-agent[26980]: Could not prepare for execution: Could not autoload puppet/indirector/certificate/rest: Invalid duration format '900 # 15 mins' for parameter: runinterval Here's the code to rest.rb require 'puppet/ssl/certificate' require 'puppet/indirector/rest' class Puppet::SSL::Certificate::Rest Puppet::Indirector::REST desc Find and save certificates over HTTP via REST. use_server_setting(:ca_server) use_port_setting(:ca_port) use_srv_service(:ca) def find(request) return nil unless result = super result.name = request.key unless result.name == request.key result end I have a very simple setup. Here is my puppet.conf: [main] server=my.server.com vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl [agent] classfile = $vardir/classes.txt localconfig = $vardir/localconfig runinterval = 900 # 15 mins syslogfacility = local4 report = true listen = true [master] syslogfacility = local4 modulepath = /etc/puppet/modules:/usr/share/puppet/modules report = true So I am guessing the runinterval = 900 is triggering the problem. But as I recall, this was set in the default puppet.conf file that was shipped. Thanks. -- 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/-/nO-1EbrdTtYJ. 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] Re: More Puppet 3.0 upgrade issues: rest.rb and runinterval ?
I fixed the problem. Seems puppet isn't smart enough to parse out a hash comment at the end of the line... that should be fixed. So, changing it from runinterval = 900 # 15 mins to: # 15 mins runinterval = 900 fixed the problem. I'll consider filing a bug report. -- 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/-/uAaknTj5y-0J. 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 3.0 fails install on Solaris 10 w/ ruby 1.8.7
There's a problem installing puppet on Solaris 10 -- in this situation, we aren't really doing anything with puppet there. The version we're using is: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-solaris2.9] Here's the first error: # gem update puppet Updating installed gems Updating puppet Building native extensions. This could take a while... ERROR: Error installing puppet: ERROR: Failed to build gem native extension. /opt/csw/bin/ruby18 extconf.rb extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) from extconf.rb:1 Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5 for inspection. Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/ext/generator/gem_make.out Nothing to update So I decided to uninstall the old version and try again: # gem uninstall puppet Remove executables: filebucket, pi, puppet, puppetdoc, ralsh, puppetca, puppetd, puppetmasterd, puppetqd, puppetrun in addition to the gem? [Yn] y Removing filebucket Removing pi Removing puppet Removing puppetdoc Removing ralsh Removing puppetca Removing puppetd Removing puppetmasterd Removing puppetqd Removing puppetrun Successfully uninstalled puppet-2.7.18 Now a fresh install: # gem install puppet Building native extensions. This could take a while... ERROR: Error installing puppet: ERROR: Failed to build gem native extension. /opt/csw/bin/ruby18 extconf.rb extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) from extconf.rb:1 Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5 for inspection. Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/ext/generator/gem_make.out The content of this last file is the same as the above error message: extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) from extconf.rb:1 Anyone know what the issue is? Thanks. -- 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/-/6bxXifJJK1AJ. 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 3.0: Not authorized to call find on /file_metadata, more issues?
I've seen mention of this error in several places, with different causes.
So before I posted here, I attempted to resolve this on my own.
I corrected the change from puppet:///files to puppet:/// in my manifests
*.pp files.
No changes were made to the auth.conf file, and I did note in the ChangeLog
that:
Auth.conf differentiates between names and IPs – There’s a new allow_ip keyword
in auth.conf if you want to permit IP addresses. (PR991)
But I see no mention of that on the docs page
at http://docs.puppetlabs.com/guides/rest_auth_conf.html.
Our auth.conf is simple, and basically has either allow $1 or allow *
both which appear to still be valid in 3.0.
Here's an example, a simple example, an ntp.conf file:
class ntp-client {
file { /etc/ntp.conf:
owner = root,
group = root,
mode= 644,
source = puppet:///etc/ntp.conf,
require = [ Package[ntp] ],
notify = Service[ntpd],
}
package { ntp:
ensure = latest,
}
service { ntpd:
ensure = running,
hasrestart = true,
subscribe = File[/etc/ntp.conf],
}
} # ntp-client
The error I'm seeing in the puppet.log, on the client system:
Oct 1 20:02:28 test-fms puppet-agent[11062]: Starting Puppet client
version 2.7.17
Oct 1 20:02:31 test-fms puppet-agent[11062]:
(/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate: Error 400
on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf Could
not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on SERVER:
Not authorized to call find on /file_metadata/etc/ntp.conf at
/etc/puppet/manifests/classes/ntp-client.pp:10
The permissions from /etc/puppet/files are correct:
-rw-r--r--. 1 puppet puppet 446 Mar 31 2011 etc/ntp.conf
The client puppet.conf file doesn't have any custom references other than
the basics.
[main]
server = ourpuppet.server.com
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
syslogfacility = local4
report = true
listen = true
I ran puppet master in verbose mode and got these diagnostics:
Starting Puppet master version 3.0.0
Info: access[^/catalog/([^/]+)$]: allowing 'method' find
Info: access[^/catalog/([^/]+)$]: allowing $1 access
Info: access[/certificate_revocation_list/ca]: allowing 'method' find
Info: access[/certificate_revocation_list/ca]: allowing * access
Info: access[/report]: allowing 'method' save
Info: access[/report]: allowing * access
Info: access[/file]: allowing * access
Info: access[/certificate/ca]: adding authentication no
Info: access[/certificate/ca]: allowing 'method' find
Info: access[/certificate/ca]: allowing * access
Info: access[/certificate/]: adding authentication no
Info: access[/certificate/]: allowing 'method' find
Info: access[/certificate/]: allowing * access
Info: access[/certificate_request]: adding authentication no
Info: access[/certificate_request]: allowing 'method' find
Info: access[/certificate_request]: allowing 'method' save
Info: access[/certificate_request]: allowing * access
Info: access[/]: adding authentication any
Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACL
Info: Inserting default '/status' (auth true) ACL
Warning: Host is missing hostname and/or domain: one-host.ourdomain.com
Compiled catalog for one-host.ourdomain.com in environment production in
1.16 seconds
Info: mount[files]: allowing 10.101.0.0/24 access
Error: Error parsing fileserver configuration: wrong number of arguments (3
for 1); using old configuration
Error: Not authorized to call find on /file_metadata/etc/ntp.conf
Error: Not authorized to call find on /file_metadata/etc/sudoers
Error: Not authorized to call find on
/file_metadata/files/etc/ssh/ssh_known_hosts
Error: Not authorized to call find on
/file_metadata/files/etc/ssh/sshd_config
Error: Not authorized to call find on
/file_metadata/etc/puppet/namespaceauth.conf
Error: Not authorized to call find on
/file_metadata/etc/puppet/puppet.conf.agent
Error: Not authorized to call find on /file_metadata/etc/puppet/auth.conf
Error: Not authorized to call find on /file_metadata/etc/resolv.conf.test
I reviewed the docs at http://docs.puppetlabs.com/guides/file_serving.html
and our config looks fine.
Reading through the issue at http://projects.puppetlabs.com/issues/16667,
I'm not clear what the fix actually is. But, our config has been
unaltered. We have unused modules in the /etc/puppet/modules directory,
where most of the little stuff has been in /etc/puppet/manifests,
referenced in site.pp by:
import classes/*
import nodes.pp
And it's worked thus far.
In the example above, with ntp-client, it's just a simple little
ntp-client.pp file that references a file that should be transfered,
nothing more. So I don't see how or why that wouldn't work
[Puppet Users] Upgrade from 2.7 to 3.0, problem with run_mode in application.rb
Just upgraded my puppet master to 3.0.0. We have a very simple setup. However, when restarting, I see this error: Starting puppetmaster: /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application.rb:273:in `run_mode': undefined method `settings' for Puppet:Module (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application/master.rb:5 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `require' from /usr/local/lib/ruby/gems/1.8/gems/puppet-2.7.19/bin/puppetmasterd:3 from /usr/local/bin/puppetmasterd:23:in `load' from /usr/local/bin/puppetmasterd:23 The code that is triggering this: # Sets or gets the run_mode name. Sets the run_mode name if a mode_name is # passed. Otherwise, gets the run_mode or a default run_mode # def run_mode( mode_name = nil) if mode_name *Puppet.settings.preferred_run_mode = mode_name* end return @run_mode if @run_mode and not mode_name require 'puppet/util/run_mode' @run_mode = Puppet::Util::RunMode[ mode_name || Puppet.settings.preferred_run_mode ] end Anyone else run into this problem? -- 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/-/ugWYcqNvHgEJ. 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] Upgrade from 2.7 to 3.0, problem with run_mode in application.rb
I'm not at PuppetConf, unfortunately. In this case, all I did was a simple CentOS service puppetmaster restart as I have in the past. But, I wonder if the fact there are older versions still present might contribute to this -- though it shouldn't be reading code from those locations. I down-rev'd back to 2.7 and it's working fine. This just seemed like an installation bug to me. On Friday, September 28, 2012 5:03:18 PM UTC-4, Jeff McCune wrote: On Fri, Sep 28, 2012 at 1:38 PM, Forrie for...@gmail.com javascript: wrote: Just upgraded my puppet master to 3.0.0. We have a very simple setup. However, when restarting, I see this error: Do you happen to be at PuppetConf? If so, I'm up on the second level and would love to work with you on this issue. Starting puppetmaster: /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application.rb:273:in `run_mode': undefined method `settings' for Puppet:Module (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application/master.rb:5 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `require' from /usr/local/lib/ruby/gems/1.8/gems/puppet-2.7.19/bin/puppetmasterd:3 from /usr/local/bin/puppetmasterd:23:in `load' from /usr/local/bin/puppetmasterd:23 How are you starting the puppet master? I'd like to try and reproduce this issue as soon as possible. I'm trying to find out if this is going to be a really common issue or if this is an isolated incident. In particular, could you provide the exact command line invocation you're using and any related environment variables? Also, what platform are you running on, and what ruby version? It looks like you're somehow getting 2.7.19 _and_ 3.0.0 in your backtraces. -Jeff -- 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/-/0vd8L0gnL98J. 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] Re: Upgrade from 2.7 to 3.0, problem with run_mode in application.rb
This is probably also the result and problem with the /etc/init.d script I have -- I think I grabbed them from the source code at some point. I'll have to see if it is a simple search-and-replace issue for that. Thanks! -- 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/-/GVs7epdDfhsJ. 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] Re: Upgrade from 2.7 to 3.0, problem with run_mode in application.rb
On a tangental note, Puppet 3.0 doesn't ship with init scripts in examples/etc/init.d -- I saw a ticket out there mentioning a need for this. I'm going to guess some others will be caught with the puppet master change.At least, the latest checkout of the GIT repo doesn't have anything in the directory but sleeper which isn't very useful. -- 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/-/AILE88ZfehoJ. 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] Iterate over array to mount NFS directories
Thank you for your reply :)
The head of the code would need something like this:
$server = nfs-server.domain.com
$prefix = /our/prefix
# Arrays to iterate over, which would be a little longer than this
$proddirs = [ 201201, 201202, 201203 ]
$testdirs = [ 201201, 201202, 201203 ]
$devdirs = [ 201201, 201202, 201203 ]
$nfsopts = tcp,hard,intr,rw,bg
By iterate I meant to work through a specific array, such as above.
Reading through the Mount part of the docs, I don't believe that absent
will remove the actual directory point, it says:
Set it to absent to unmount (if necessary) and remove the filesystem from
the fstab
So I would handle that by running another iteration over an array for each
section that would have a routine to make sure it's absent and then also
rmdir the entry in the filesystem.
I'm not understanding where the below is iterating or over where... as
$name would need to be defined somehow.
Thanks!
On Tuesday, September 25, 2012 5:09:15 AM UTC-4, Luke Bigum wrote:
Hi Forrie,
With regards to your iteration question, you would need to use a defined
type, something like this (untested):
define nfs_mount ( $server, $prefix, $state = mounted ) {
$mount_point = ${prefix}/${name}
#If the state is unmounted the mount point 'File' is removed
file { $mount_point:
ensure = $state ? {
unmounted = absent,
absent = absent,
default = present,
}
}
mount { $mount_point:
ensure = $state,
device = {$server}:${mount_point},
}
}
nfs_mount { $production: server = $server, prefix = $prefix}
See the documentation for the Mount type in Puppet and it's ensure
parameter for possible values for $state in the define above - it's
possible to have entries in /etc/fstab but not actually mounted, which
should satisfy your two stage cleanup, or you can just set $state to
'absent' straight away and clean up the both NFS mount and mount point.
This means you need to maintain two arrays: one of active mount points
and one of decomissioned mounts, however you probably don't need to keep
the decomissioned mounts around for ever, once every server has cleaned
themselves up they can be removed from the manifest.
http://docs.puppetlabs.com/references/latest/type.html#mount
Hope that helps,
-Luke
On 24/09/12 23:43, Forrie wrote:
I have many systems that require NFS mounts for production. Rather
than have one entry of file{} and mount{} per NFS import, in a *.pp
file, I'd rather set up and iterate over an array. Looking at the
docs, I'm not quite sure how to do this properly. We have three
groups for which I would need this (production, development, test)
that each have their own NFS mounts.
here's what I would use:
$server = server.name.com
$prefix = /some/nfs/root
# array
production = [
dir1,
dir2,
dir3,
dir4,
] # etc etc
Then issue a command to iterate and manage those NFS mounts.
Since these change from time-to-time, and require some pruning... I
will be left with unmanaged resources (ie: directory mount points)
scattered around that I will need to clean up. I read through some
tickets for feature requests and got lost in where this is going --
however, to keep the place neat and clean, I'd like to unmanage the
mount points and the fstab entries after. The idea of manually doing
this from system to system isn't good.
I'm still new-ish to puppet, so any pointers would be appreciated.
Thanks.
--
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/-/MQ9gniWF4gUJ.
To post to this group, send email to
puppet...@googlegroups.comjavascript:.
To unsubscribe from this group, send email to
puppet-users...@googlegroups.com javascript:.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Senior Systems Engineer
Information Systems
Ph: +44 (0) 20 3192 2520
luke@lmax.com javascript: | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee
[Puppet Users] Iterate over array to mount NFS directories
I have many systems that require NFS mounts for production. Rather than
have one entry of file{} and mount{} per NFS import, in a *.pp file, I'd
rather set up and iterate over an array. Looking at the docs, I'm not
quite sure how to do this properly. We have three groups for which I would
need this (production, development, test) that each have their own NFS
mounts.
here's what I would use:
$server = server.name.com
$prefix = /some/nfs/root
# array
production = [
dir1,
dir2,
dir3,
dir4,
] # etc etc
Then issue a command to iterate and manage those NFS mounts.
Since these change from time-to-time, and require some pruning... I will be
left with unmanaged resources (ie: directory mount points) scattered
around that I will need to clean up. I read through some tickets for
feature requests and got lost in where this is going -- however, to keep
the place neat and clean, I'd like to unmanage the mount points and the
fstab entries after. The idea of manually doing this from system to
system isn't good.
I'm still new-ish to puppet, so any pointers would be appreciated.
Thanks.
--
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/-/MQ9gniWF4gUJ.
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] Re: Puppet and Ruby 1.9
Thanks everyone for your replies. I've been waiting to upgrade our infrastructure to 1.9. We don't do any esoterica, it's just a simple puppet setup (for the time being) - not even marionette. I switched our config to use an NFS mount for puppet and ruby (configs stored locally on each machine, still) and so far it's worked fine. So I don't anticipate any version conflict with ruby and puppet. The SSL bug didn't show up on the redmine page. The others seem like they might not affect me at this time. -- 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 and Ruby 1.9
What is the status of compatibility with Puppet 2.7.16+ and Ruby 1.9? I searched through this group and found some older posts. I am not certain what the core issues are (and there's probably a PuppetLabs page for it, I bet). 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.
[Puppet Users] Re: Case statements in a file directive
So there were two gotchas :-) One, my mis-typed / and the other the missing ? in the evaluation ;-) Thanks again, guys, I appreciate the feedback. -- 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] Re: Case statements in a file directive
Thank you, I appreciate it.Still learning all the interesting nuances of this syntax. I'm not yet familiar with this $:: -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Case statements in a file directive
So, it's choking on this still at the line with the conditional:
Apr 17 18:58:17 test-system puppet-agent[7590]: Could not retrieve
catalog from remote server: Error 400 on SERVER: Could not parse for
environment production: Syntax error at '{'; expected '}' at /etc/
puppet/manifests/classes/nagios-client-test.pp:20 on node test-
system.my-domain.com
The brackets look balanced to me.
file { /usr/local/nagios/libexec:
require = File['/usr/local/nagios'],
ensure = directory,
owner = 'root',
group = 'root',
mode= 655,
recurse = true,
source = $::architecture {
/(i386|i586|i686/) = puppet:///files/32/usr/local/
nagios/libexec,
x86_64 = puppet:///files/64/usr/local/
nagios/libexec,
}
}
--
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] Case statements in a file directive
I want to distribute a binary directory based upon whether the
architecture is 32- or 64-bit. It appears I cannot nest a case
statement under file, however this is what I was attempting to do:
file { /usr/local/nagios/libexec:
require = File['/usr/local/nagios'],
ensure = directory,
owner = 'root',
group = 'root',
mode= 655,
recurse = true,
## APPEARS I can't do this
case $architecture {
/(i386|i586|i686/): {
source = puppet:///files/32/usr/local/nagios/
libexec
}
x86_64: {
source = puppet:///files/64/usr/local/nagios/
libexec
}
}
}
I know I could reverse it and do a case first, then have redundant
file {} declarations, but that seems just that, redundant.
Can anyone point out what I'm doing wrong here. The output in the
puppet logs isn't generally helpful with debugging.
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.
[Puppet Users] Re: Puppet in NFS fools Facter
Nothing was copied over. The NFS mount code was built and then exported; 32- and 64-bit respectively. The code was built from scratch and installed with the appropriate locally mounted prefix (in this case, /local). I'm on RHEL 5.x and we only have /proc/self/status which doesn't seem to indicate anything about virtual or physical, for example: Name: cat State: R (running) SleepAVG: 88% Tgid: 1523 Pid:1523 PPid: 31949 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 VmPeak:58952 kB VmSize:58952 kB VmLck: 0 kB VmHWM: 484 kB VmRSS: 484 kB VmData: 176 kB VmStk:88 kB VmExe:20 kB VmLib: 1448 kB VmPTE:40 kB StaBrk: 06dd2000 kB Brk:06df3000 kB StaStk: 7fffb84776a0 kB Threads:1 SigQ: 1/4096 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: feff CapEff: feff Cpus_allowed: ,,,,,,,0003 Mems_allowed: ,0001 -- 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] Re: Puppet in NFS fools Facter
Interestingly, the command facter serialnumber correctly pulls that it's a VMware system: # /local/bin/facter serialnumber VMware-56 4d 00 7e e8 3b e8 c9-85 7f 4e XX XX XX XX XX -- 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] Re: Puppet in NFS fools Facter
On another system, same NFS mounts, the facter virtual reports the correct information, that system is running: 2.6.18-194.3.1.el5 The system that doesn't correctly report is: 2.6.18-274.18.1.el5 I don't know if that really matters. -- 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] Wrong header line format errors
I've not made any changes to the config recently, only keeping Puppet and ruby 1.8 up-to-date. Recently, I noted my systems are logging this ambiguous error: Could not retrieve catalog from remote server: wrong header line format I say ambiguous as a google search shows serveral things this could be related to. I'm not sure what this really means, or whether it means something stored on the puppet master is corrupted. Can someone point me in the right direction? 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.
[Puppet Users] Re: Wrong header line format errors
I answered my own question. It seems there was a missing ' or in one of the configs -- reported in the HTTP log. But the error itself doesn't tell me much. 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.
[Puppet Users] Setting password hash for virtual users?
I read that this doesn't always work on every OS. However, I'm on
RHEL, and from what I'm reading the following should correctly set /
etc/shadow:
@user { myuser:
require= Group['staff'],
ensure = present,
uid= '2345',
gid= '90',
shell = '/bin/bash',
comment= 'myuser',
home = '/home/myuser',
managehome = true,
password = $1$BfhBSUJv$ajfjgfhdskdgfljkfdglkjfdlkfd., #
fake hash for this post
}
It creates the user and dependency, but doesn't touch /etc/shadow.
I need to be able to set this hash with the virtual user for the
systems we manage.Is there some workaround for this, or is my
syntax incorrect?
--
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 in NFS fools Facter
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.
[Puppet Users] Re: Puppet in NFS fools Facter
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.
[Puppet Users] Re: Deploying puppet via NFS
I installed this using the full path to the shared gem, simply: /local/bin/gem install puppet The puppet code, et al, is in the proper place under /local/lib/ I don't need to worry about the installation, I can overwrite it any time -- this is my test platform. I did bootstrap ruby and installed it in /local via ./configure -- prefix=/local and it installed fine, too. -- 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] Re: Deploying puppet via NFS
Here are the errors in full, and demonstrating the entire path: [ /local]# bin/gem list *** LOCAL GEMS *** facter (1.6.5) puppet (2.7.11) [ /local]# bin/puppet --version /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- openssl (LoadError) from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/lib/puppet/ssl.rb:3 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/lib/puppet.rb:155 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/lib/puppet/ application.rb:272:in `initialize' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/lib/puppet/util/ command_line.rb:60:in `new' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/lib/puppet/util/ command_line.rb:60:in `execute' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.11/bin/puppet:4 from bin/puppet:19:in `load' from bin/puppet:19 [ /local]# bin/ruby --version ruby 1.8.7 (2012-02-08 patchlevel 358) [i686-linux] -- 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] Re: Deploying puppet via NFS
Did you build this on a system with openssl-devel or equivalent installed? Or install openssl+devel headers into your /local location? BINGO! That was the problem. THANK YOU. What really gets me is that I would never have figured this out, based on the ambiguous error message. I just recompiled, reinstalled and now puppet works. I'm going to now test deploying this via NFS -- separate 32bit and 64bit mounts. Has anyone done this before. I realize the next step will be storedconfigs so that a minimal amount of data is needed on each host. I just haven't found any information out there about anyone having done this via NFS. 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.
[Puppet Users] Re: Deploying puppet via NFS
I built Ruby with: ./configure --prefix=/local I see that you can specify a number of options with ./configure, including: --with-sitedir=DIR site libraries in DIR [LIBDIR/ruby/site_ruby] but the defaults for this should just work with that switch. I see these options, too: --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX --bindir=DIRuser executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIRprogram executables [EPREFIX/libexec] --libdir=DIRobject code libraries [EPREFIX/lib] I've never had to specify anything other than the above ./configure switch before. All of my other systems work fine. It's just this bit with the NFS mount. The client system in question does not have any other ruby or puppet installations on it. 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.
[Puppet Users] Re: Deploying puppet via NFS
Also, the puppet I'm using (on all systems) is installed from the gem. -- 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] Re: Deploying puppet via NFS
This is probably not an issue with the executable search path, but rather with the Ruby path. It looks like whichever Ruby interpreter you are using to run Puppet is unable to find one of the files (probably openssl.rb) that it expects to see in the Ruby library. The Ruby interpreter in use will probably be controlled by the puppet[d] script, not directly by the initscript that launches it, and the interpreter will have its own ideas of where its library is supposed to be. If I were pursuing your approach, I would put a complete Ruby installation on the share, and install Puppet and all the needed dependencies into that. Then I would be sure to launch Puppet using *that* Ruby, not, for instance, the system's Ruby. It's not clear to me whether that's what you're already trying to do, but if so, then I don't think you've gotten it completely right. John This is what I did, I did a make/make install into the shared location. But I wonder if there is some hard-coded PATH in there somewhere. I'll have to poke around. I don't see where I can do a trace on executing this to see what it's calling. 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.
[Puppet Users] Re: Deploying puppet via NFS
This must have to do with an include path, as here is where I find the code: /local/lib/ruby/site_ruby/1.8/rubygems/gem_openssl.rb it's been a while, but I think the SITE_RUBY include is configured somewhere - and that may be the issue. -- 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] Re: Deploying puppet via NFS
I just did a basic find statement and found:
# pwd
/local/lib/ruby/gems/1.8/gems/puppet-2.7.11
# find . -exec grep -i site_ruby {} \;
SITELIBDIR=/usr/lib/ruby/site_ruby/1.8
sitelibdir = $LOAD_PATH.find { |x| x =~ /site_ruby/ }
sitelibdir = File.join(libdir, site_ruby)
#{work}/usr/lib/ruby/site_ruby/1.8/puppet]
system(#{DITTO} #{puppet_source}/lib/ #{work}/usr/lib/ruby/
site_ruby/1.8/)
system(#{SED} -i '' \s\#{SITELIBDIR}\#/usr/lib/ruby/site_ruby/
1.8\#g\ #{@working_tree['scripts']}/preflight)
FileUtils.chmod_R(0644, #{work}/usr/lib/ruby/site_ruby/1.8/)
FileUtils.chown_R('root', 'wheel', #{work}/usr/lib/ruby/site_ruby/
1.8/)
Find.find(#{work}/usr/lib/ruby/site_ruby/1.8/) do |dir|
# into RUBY's site_ruby directory. If you run into strange problems,
make sure
Puppet should not be installed in site_ruby because all of \$LOAD_PATH
Somewhere, puppet is not inheriting the correct PATH to site_ruby.
--
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] Deploying puppet via NFS
I'm attempting to deploy puppet via an NFS share. It's on a local-only network, and it will contain only ruby (gems) and whatever is needed. Seems simple enough, but tonight I am having an issue with this error: # service puppet start Starting puppet: /local/lib/ruby/site_ruby/1.8/rubygems/ custom_require.rb:36:in `gem_original_require': no such file to load -- openssl (LoadError) from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ssl.rb:3 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet.rb:155 from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' from /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:271:in `initialize' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:229:in `new' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/lib/puppet/ application.rb:229:in `[]' from /local/lib/ruby/gems/1.8/gems/puppet-2.7.9/bin/puppetd:4 from /local/bin/puppetd:19:in `load' from /local/bin/puppetd:19 I did a search for this general error and it seems to come up with different circumstances. I checked the $PATH in the startup script, I can run ruby/irb alone with no trouble. All of my other systems do not have any supplemental GEMs that deal with SSL. There's nothing else on this system, no other ruby. Seems like it might be a simple thing - but I wonder what the problem is? I've been poring over this for a while... I can't see it. 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.
[Puppet Users] Recent updates to ruby break puppet
I went to update our ruby-1.8 installation and unfortunately, it appears to have broken something that Puppet depends on: # service puppetmaster start Starting puppetmaster: /usr/lib/ruby/site_ruby/1.8/rubygems.rb:334: warning: parenthesize argument(s) for future version /usr/lib/ruby/site_ruby/1.8/rubygems.rb:516: warning: parenthesize argument(s) for future version /usr/lib/ruby/site_ruby/1.8/rubygems.rb:32:in `require': /usr/lib/ruby/ site_ruby/1.8/rubygems/deprecate.rb:54: syntax error, unexpected ',', expecting '|' (SyntaxError) ... define_method name do |*args, block| # TODO: really works ... ^ /usr/lib/ruby/site_ruby/1.8/rubygems/deprecate.rb:55: syntax error, unexpected tCONSTANT, expecting '}' /usr/lib/ruby/site_ruby/1.8/rubygems/deprecate.rb:64: syntax error, unexpected kEND, expecting '}' /usr/lib/ruby/site_ruby/1.8/rubygems/deprecate.rb:69: syntax error, unexpected kEND, expecting '}' from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:32 from /usr/bin/puppetmasterd:9:in `require' from /usr/bin/puppetmasterd:9 I'm going to downgrade back to the old version. Does anyone know what the issue is and whether there is a forthcoming fix or workaround? 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.
[Puppet Users] Re: Recent updates to ruby break puppet
Nevermind, I accidentally built in the wrong directory an older version. -- 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] Using an array to manage a string of directories that need to be managed
I've read previous posts about iterating over arrays, hashes, etc.
I have a series of directories that need to be created (and
maintained, with appropriate permissions) that serve as NFS mount
points on a series of systems.Sometimes, when they are no longer
needed, they will be removed (another issue).
I thought I could just create a simple array and then use a file {}
statement to ensure they are created. Seems simple enough. Some
don't feel that's the most efficient way.
Since I'm going to be using autofs to ensure the mounts exist, I
suppose I could craft a template which could make use of this array
and then ship out the autofs configuration to each system, as a
dependency.
Might someone offer advice on how to best handle this one.
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.
[Puppet Users] Re: Managing entries in /etc/group (membership)
I want to manage the membership of the /etc/group entry -- this is just until we get things moved into LDAP -- so there aren't any virtual users to be connected with it. I had thought there was a function to work with this, I could be mistaken. On Oct 17, 6:18 pm, Christopher Wood christopher_w...@pobox.com wrote: The user type allows you to specify supplemental groups (see the groups parameter). Is that what you were looking for? http://docs.puppetlabs.com/references/stable/type.html#user On Mon, Oct 17, 2011 at 03:04:26PM -0700, Forrie wrote: I have a requirement to manage membership to groups in /etc/group. These members do not need to be virtual users. I don't see a way to do this through virtual users @group. How are others doing this? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group athttp://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.
[Puppet Users] Re: Managing entries in /etc/group (membership)
We aren't using LDAP yet... On Oct 17, 6:50 pm, Christopher Wood christopher_w...@pobox.com wrote: If you're using ldap, why not handle groups there? On Mon, Oct 17, 2011 at 03:48:33PM -0700, Forrie wrote: I want to manage the membership of the /etc/group entry -- this is just until we get things moved into LDAP -- so there aren't any virtual users to be connected with it. I had thought there was a function to work with this, I could be mistaken. On Oct 17, 6:18 pm, Christopher Wood christopher_w...@pobox.com wrote: The user type allows you to specify supplemental groups (see the groups parameter). Is that what you were looking for? http://docs.puppetlabs.com/references/stable/type.html#user On Mon, Oct 17, 2011 at 03:04:26PM -0700, Forrie wrote: I have a requirement to manage membership to groups in /etc/group. These members do not need to be virtual users. I don't see a way to do this through virtual users @group. How are others doing this? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group athttp://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 athttp://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.
[Puppet Users] RHEL 5.x remount an invalid option to NFS?
I made an adjustment to my puppet config for three systems today, which has the remount option set to true in the *.pp, and I see this in the logs on my systems: Execution of '/bin/mount -o remount /home/directory' returned 32: mount.nfs: Invalid argument remount is valid to the mount command, but not to the mount.nfs command on RHEL. I'm not really sure if this is important or how to get around this -- or if this is a bug. 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.
[Puppet Users] Re: Using Mcollective with Enterprise Ruby
Where is the plugins directory supposed to be installed/located? -- 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] Re: Using Mcollective with Enterprise Ruby
As I've gotten to the point of configuring server.cfg and client.cfg, based on the documentation in Pro Puppet (which also references use of RPMs), it seems we have some configuration issues -- perhaps about standards of where things need to be located. The book refers to a non-existent directory, /usr/share/mcollective/ plugins. The RPMs create /etc/mcollective/plugin.d (empty). Thus, when you start the server, it fails with the following errors: E, [2011-06-28T16:16:19.419481 #25040] ERROR -- : pluginmanager.rb: 111:in `loadclass' Failed to load Mcollective::Facts::Yaml_facts: no such file to load -- mcollective/facts/yaml_facts.rb E, [2011-06-28T16:16:19.419708 #25040] ERROR -- : pluginmanager.rb: 111:in `loadclass' Failed to load Mcollective::Connector::Stomp: n o such file to load -- mcollective/connector/stomp.rb E, [2011-06-28T16:16:19.419891 #25040] ERROR -- : pluginmanager.rb: 111:in `loadclass' Failed to load Mcollective::Security::Psk: no s uch file to load -- mcollective/security/psk.rb E, [2011-06-28T16:16:19.420036 #25040] ERROR -- : pluginmanager.rb: 111:in `loadclass' Failed to load Mcollective::Registration::Agent list: no such file to load -- mcollective/registration/agentlist.rb I, [2011-06-28T16:16:19.420433 #25040] INFO -- : mcollectived:31 The Marionette Collective 1.2.0 started logging at info level I could be mistaken. What's missing? -- 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.
