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:
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
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.
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
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
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
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
, 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
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
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
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
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
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:
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
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
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
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
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
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
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
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?
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,
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
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
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 =
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
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
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
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)
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
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
[ ... ]
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
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
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
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
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
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 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
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
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
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
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
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
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
:-)
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
: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
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,
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.
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
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
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
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
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?
--
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.
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
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
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
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
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
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
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
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
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
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)
-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
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
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
... 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
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
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
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
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
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
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/
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'],
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
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
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
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
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
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',
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
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
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
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
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
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:
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
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
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
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)
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/
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
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
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
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
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
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,
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
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
1 - 100 of 165 matches
Mail list logo
