Puppet users - Jun 2010 - bringing puppet into production

Hi everyone,

I’ve been working on getting puppet set up for our systems for the
past week, and all has gone well in learning about writing manifests,
but now that I’m ready to set it into production, I realize that it’s
still unclear to me exactly how that’s supposed to go.

For instance, during testing it has always been that I manually
started and stopped puppetd and puppetmasterd on their respective
machines with the following commands

node1 $ puppetd --server servercharlie.bestgroup --waitforcert 60 --
test

and on the master

master $ puppetmasterd --debug --no-daemonize

But now that it’s time for production, trying to start the puppetd
with my init script, yielded the following error:

chown: invalid user: ‘puppet:puppet’

which made me realize that I haven’t done anything in terms of
configuration on the nodes; I simply always ran the above command.

So, I have a few specific questions about this, but I’d also
appreciate any insight into things that I might fail to ask, but could
be relevant to this topic.

1. The init scripts supplied by the Debian package (which I’m actually
not using, I’m just using the init scripts, logrotate.d and /etc/
default files, etc) only act on puppetd. So then how is the
puppetmasterd supposed to be started on the master node? I know the
init scripts can be written. I have no fear of that, but I do get the
feeling that I’m missing something.

2. I never really saw where in the documentation puppet.conf file is
addressed. I’ve seen that it’s pretty well documented, but again, did
I miss something, especially considering that I have gone through the
online manifest-writing/language documentation for the past week, and
through all of the testing, I never once did something to configure
the client nodes. As mentioned above, I simply ran the puppetd
command.

Okay, for specific questions that covers it for now, but like I said,
if there is any other general advice in terms these aspects of puppet,
that would be appreciated too.

As a final note, I should probably point out that I have a Debian
system, but that I haven’t used their package because their libraries
tend to be quite old, and we’ve had a couple of instances where the
web-apps that we develop have actually been derailed because of old
ruby libraries that come as dependencies for these older packages.

Anyway, thanks in advance.

Regards,
Chris

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 20.06.2010 12:38, Christopher wrote:
> Hi everyone,
>
> I’ve been working on getting puppet set up for our systems for the
> past week, and all has gone well in learning about writing manifests,
> but now that I’m ready to set it into production, I realize that it’s
> still unclear to me exactly how that’s supposed to go.
>
> For instance, during testing it has always been that I manually
> started and stopped puppetd and puppetmasterd on their respective
> machines with the following commands
>
> node1 $ puppetd --server servercharlie.bestgroup --waitforcert 60 --
> test
>
> and on the master
>
> master $ puppetmasterd --debug --no-daemonize
>
> But now that it’s time for production, trying to start the puppetd
> with my init script, yielded the following error:
>
> chown: invalid user: ‘puppet:puppet’
>
> which made me realize that I haven’t done anything in terms of
> configuration on the nodes; I simply always ran the above command.
>
> So, I have a few specific questions about this, but I’d also
> appreciate any insight into things that I might fail to ask, but could
> be relevant to this topic.
>
> 1. The init scripts supplied by the Debian package (which I’m actually
> not using, I’m just using the init scripts, logrotate.d and /etc/
> default files, etc) only act on puppetd. So then how is the
> puppetmasterd supposed to be started on the master node? I know the
> init scripts can be written. I have no fear of that, but I do get the
> feeling that I’m missing something.
>    
You should only use the default scripts for puppetmaster only in 
developement. The puppetmaster daemon (around version 0.24.8) kept 
hanging. But a lot has changed since then. I''m not even sure if
it''s
still running via webrick or if it has been updated to mongrel. As of 
the 0.24.8 I switched to using passenger with apache so I''m not up to 
date with the changes related to the puppetmaster daemon.

My advice is to either use mongrel or passenger with a production 
system, and I think this is generally accepted on this list.(please do 
correct me if I''m wrong)
> 2. I never really saw where in the documentation puppet.conf file is
> addressed. I’ve seen that it’s pretty well documented, but again, did
> I miss something, especially considering that I have gone through the
> online manifest-writing/language documentation for the past week, and
> through all of the testing, I never once did something to configure
> the client nodes. As mentioned above, I simply ran the puppetd
> command.
>    
The defaults are usally fine, but you milage may vary, depending on what 
you want to do (exported resources, puppet dashboard, foreman, tagmail etc)
You may want to look into the options certname, certdnsnames, confdir, 
manifestdir, modulepath, manifest, pluginsync, server (this list is for 
both server and client)
> Okay, for specific questions that covers it for now, but like I said,
> if there is any other general advice in terms these aspects of puppet,
> that would be appreciated too.
>
> As a final note, I should probably point out that I have a Debian
> system, but that I haven’t used their package because their libraries
> tend to be quite old, and we’ve had a couple of instances where the
> web-apps that we develop have actually been derailed because of old
> ruby libraries that come as dependencies for these older packages.
>
> Anyway, thanks in advance.
>
>    
 From my experince I prefer the packages, either source recompiled for 
the current distro or from backports. It''s easier to upgrade IMHO. I 
usally rebuild the debian packages for ubuntu, as ubuntu lags a version 
or 2 behind debian sid/squeeze. I''m guessing you''re using
lenny, since
squeeze and sid are somewhat up to date. Anyhow if your system is not 
using packages it is probably easier without packages, but you should 
think if it would not be easier to create a local repository for your 
packages and install them via packages.

Good luck with your new install,
Silviu

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

You''ve got some problems that are caused because the packages
didn''t do things you need done, and other problems that are unrelated.

On the clients, puppetd will automatically look for the server at puppet, and
should use the search domain.  You really want to change DNS so that the
puppetmaster has a DNS name of puppet.  If it''s working, "ping
puppet" should ping the puppet master.  At this point the server flag
should be needed anymore.

On the master, you need to create a user and group called puppet.  This user
needs read-only access to everything in/etc/puppet and read-write access to
everything in /var/lib/puppet.  (These are standard locations for Debian, but
they might be in a different place in your version of puppet.  Some of the files
in these directories should not be world-readable, so it''s easier to
just make both of them be not world-readable.

I''m assuming that you are using puppet version 0.25.4 or above.  If you
aren''t, you should upgrade now.

For startup scripts, it''s probably easier to get the scripts from the
official packages or the examples than it is to write your own.

Hints:
puppetd is normally be run as root so it can administrate your (puppet) clients.
puppetmaster is normally run as puppet because it doesn''t need to make
changes to the server.

Summery:
1) Make sure that running "ping puppet" on the client pings the
server.
2) Add a user called puppet
3) Add a group called puppet
4) chown -R root:puppet /etc/puppet
5) chown -R puppet:puppet /var/lib/puppet
6) Set permissions on /etc/puppet to 640 and 750
7) Set permissions on /var/lib/puppet to 660 and 770

PS if you aren''t using version control yet, start using it now.  Even
if you don''t use comments, tags, and branches, it will still allow you
to:
1) Revert stupid mistakes
2) Do a binary search through your revisions to find out what change caused a
bug.


On Jun 20, 2010, at 2:38 AM, Christopher wrote:
> Hi everyone,
> 
> I’ve been working on getting puppet set up for our systems for the
> past week, and all has gone well in learning about writing manifests,
> but now that I’m ready to set it into production, I realize that it’s
> still unclear to me exactly how that’s supposed to go.
> 
> For instance, during testing it has always been that I manually
> started and stopped puppetd and puppetmasterd on their respective
> machines with the following commands
> 
> node1 $ puppetd --server servercharlie.bestgroup --waitforcert 60 --
> test
> 
> and on the master
> 
> master $ puppetmasterd --debug --no-daemonize
> 
> But now that it’s time for production, trying to start the puppetd
> with my init script, yielded the following error:
> 
> chown: invalid user: ‘puppet:puppet’
> 
> which made me realize that I haven’t done anything in terms of
> configuration on the nodes; I simply always ran the above command.
> 
> So, I have a few specific questions about this, but I’d also
> appreciate any insight into things that I might fail to ask, but could
> be relevant to this topic.
> 
> 1. The init scripts supplied by the Debian package (which I’m actually
> not using, I’m just using the init scripts, logrotate.d and /etc/
> default files, etc) only act on puppetd. So then how is the
> puppetmasterd supposed to be started on the master node? I know the
> init scripts can be written. I have no fear of that, but I do get the
> feeling that I’m missing something.
> 
> 2. I never really saw where in the documentation puppet.conf file is
> addressed. I’ve seen that it’s pretty well documented, but again, did
> I miss something, especially considering that I have gone through the
> online manifest-writing/language documentation for the past week, and
> through all of the testing, I never once did something to configure
> the client nodes. As mentioned above, I simply ran the puppetd
> command.
> 
> Okay, for specific questions that covers it for now, but like I said,
> if there is any other general advice in terms these aspects of puppet,
> that would be appreciated too.
> 
> As a final note, I should probably point out that I have a Debian
> system, but that I haven’t used their package because their libraries
> tend to be quite old, and we’ve had a couple of instances where the
> web-apps that we develop have actually been derailed because of old
> ruby libraries that come as dependencies for these older packages.
> 
> Anyway, thanks in advance.
> 
> Regards,
> Chris
> 
> -- 
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
>> 2. I never really saw where in the documentation puppet.conf file is
>> addressed. I’ve seen that it’s pretty well documented, but again, did
>> I miss something, especially considering that I have gone through the
>> online manifest-writing/language documentation for the past week, and
>> through all of the testing, I never once did something to configure
>> the client nodes. As mentioned above, I simply ran the puppetd
>> command.
> The defaults are usally fine, but you milage may vary, depending on 
> what you want to do (exported resources, puppet dashboard, foreman, 
> tagmail etc)
> You may want to look into the options certname, certdnsnames, confdir, 
> manifestdir, modulepath, manifest, pluginsync, server (this list is 
> for both server and client)
Okay, so is puppet.conf for puppetd, puppetmasterd, or all of the puppet 
components?
>
> From my experince I prefer the packages, either source recompiled for 
> the current distro or from backports. It''s easier to upgrade IMHO.
I
> usally rebuild the debian packages for ubuntu, as ubuntu lags a 
> version or 2 behind debian sid/squeeze. I''m guessing
you''re using
> lenny, since squeeze and sid are somewhat up to date. Anyhow if your 
> system is not using packages it is probably easier without packages, 
> but you should think if it would not be easier to create a local 
> repository for your packages and install them via packages.
Yes, I am using Lenny, and I''ve gone the deb making route before.
I''ll
consider it again, but since that''s usually a bit of an investment of 
time, it just seemed like a bit of a detour from getting started with 
puppet.

Unfortunately, we''ve just had to put forth a real effort to try to not 
use any of the standard Debian ruby stuff. The interpreter and a handful 
of gems is fine, but then everything else, we install ourselves. 
Actually at this point we''ve also abandoned the interpreter in favor or
Ruby enterprise, but that''s another thread :)

Thanks for the feedback.

Regards,
Chris


-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Chris,

On Sun, Jun 20, 2010 at 11:26 PM, christopher floess
<skeptikos@gmail.com>wrote:
>
>
>
>>  2. I never really saw where in the documentation puppet.conf file is
>>> addressed. I’ve seen that it’s pretty well documented, but again,
did
>>> I miss something, especially considering that I have gone through
the
>>> online manifest-writing/language documentation for the past week,
and
>>> through all of the testing, I never once did something to configure
>>> the client nodes. As mentioned above, I simply ran the puppetd
>>> command.
>>>
>> The defaults are usally fine, but you milage may vary, depending on
what
>> you want to do (exported resources, puppet dashboard, foreman, tagmail
etc)
>> You may want to look into the options certname, certdnsnames, confdir,
>> manifestdir, modulepath, manifest, pluginsync, server (this list is for
both
>> server and client)
>>
> Okay, so is puppet.conf for puppetd, puppetmasterd, or all of the puppet
> components?

it has sections:

[main]
# applies to all
[puppetmaster]
# overrides main, server only
[puppetd]
# client only
[puppet]
# only puppet executable

>> From my experince I prefer the packages, either source recompiled for
the
>> current distro or from backports. It''s easier to upgrade IMHO.
I usally
>> rebuild the debian packages for ubuntu, as ubuntu lags a version or 2
behind
>> debian sid/squeeze. I''m guessing you''re using lenny,
since squeeze and sid
>> are somewhat up to date. Anyhow if your system is not using packages it
is
>> probably easier without packages, but you should think if it would not
be
>> easier to create a local repository for your packages and install them
via
>> packages.
>>
> Yes, I am using Lenny, and I''ve gone the deb making route before.
I''ll
> consider it again, but since that''s usually a bit of an investment
of time,
> it just seemed like a bit of a detour from getting started with puppet.
>
> Unfortunately, we''ve just had to put forth a real effort to try to
not use
> any of the standard Debian ruby stuff. The interpreter and a handful of
gems
> is fine, but then everything else, we install ourselves. Actually at this
> point we''ve also abandoned the interpreter in favor or Ruby
enterprise, but
> that''s another thread :)
>
> Thanks for the feedback.
>
> Regards,
> Chris
>
>
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
regards,

Dan Bode

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 06/20/2010 08:47 PM, Patrick Mohr wrote:
> You''ve got some problems that are caused because the packages
didn''t do things you need done, and other problems that are unrelated.
>
> On the clients, puppetd will automatically look for the server at puppet,
and should use the search domain.  You really want to change DNS so that the
puppetmaster has a DNS name of puppet.  If it''s working, "ping
puppet" should ping the puppet master.  At this point the server flag
should be needed anymore.
>    
So the certificate would need to be regenerated at this point. Is it 
just a matter of:

Is it a matter of changing:

1. certname = servercharlie.bestgroup

to

certname = puppet

2. restart puppetmasterd (does puppetmasterd know to reconfigure the 
certificates?)

3. change /etc/hosts/ entry on client node (I guess /etc/puppet/ssl/ has 
to be deleted?)

4. rerun puppetca on the master.

Sorry, this may seem trivial, but I don''t feel like breaking the setup 
at this point.
> On the master, you need to create a user and group called puppet.  This
user needs read-only access to everything in/etc/puppet and read-write access to
everything in /var/lib/puppet.  (These are standard locations for Debian, but
they might be in a different place in your version of puppet.  Some of the files
in these directories should not be world-readable, so it''s easier to
just make both of them be not world-readable.
>
> I''m assuming that you are using puppet version 0.25.4 or above. 
If you aren''t, you should upgrade now.
>    
I am.
> For startup scripts, it''s probably easier to get the scripts from
the official packages or the examples than it is to write your own.
>    
I did.
> Hints:
> puppetd is normally be run as root so it can administrate your (puppet)
clients.
> puppetmaster is normally run as puppet because it doesn''t need to
make changes to the server.
>
> Summery:
> 1) Make sure that running "ping puppet" on the client pings the
server.
> 2) Add a user called puppet
> 3) Add a group called puppet
> 4) chown -R root:puppet /etc/puppet
> 5) chown -R puppet:puppet /var/lib/puppet
> 6) Set permissions on /etc/puppet to 640 and 750
> 7) Set permissions on /var/lib/puppet to 660 and 770
>    
Summaries are nice :) Seems like I have most of this covered. I''m going
to check the permissions again. I also wasn''t able to find any log
files
when I wanted to watch them one time, but I imagine that I can address 
this in the config.
> PS if you aren''t using version control yet, start using it now. 
Even if you don''t use comments, tags, and branches, it will still allow
you to:
> 1) Revert stupid mistakes
> 2) Do a binary search through your revisions to find out what change caused
a bug.
>    
I am using version control. It does feel sort of weird having a git 
repository in /etc/ though.

Thanks.

Regards,
Chris

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 21, 2010, at 12:04 AM, christopher floess wrote:
> 
> 
> On 06/20/2010 08:47 PM, Patrick Mohr wrote:
>> You''ve got some problems that are caused because the packages
didn''t do things you need done, and other problems that are unrelated.
>> 
>> On the clients, puppetd will automatically look for the server at
puppet, and should use the search domain.  You really want to change DNS so that
the puppetmaster has a DNS name of puppet.  If it''s working, "ping
puppet" should ping the puppet master.  At this point the server flag
should be needed anymore.
>>   
> So the certificate would need to be regenerated at this point. Is it just a
matter of:
> 
> Is it a matter of changing:
> 
> 1. certname = servercharlie.bestgroup
> 
> to
> 
> certname = puppet
> 
> 2. restart puppetmasterd (does puppetmasterd know to reconfigure the
certificates?)
> 
> 3. change /etc/hosts/ entry on client node (I guess /etc/puppet/ssl/ has to
be deleted?)
> 
> 4. rerun puppetca on the master.
> 
> Sorry, this may seem trivial, but I don''t feel like breaking the
setup at this point.
Because you don''t want to re-setup the clients, or because
you''re worried about breaking it?  Actually, the certificate might
already have "puppet" and "puppet.bestgroup" as aliases.


On the other hand, I was assuming you control DNS for all the clients in one or
two central locations.  If you aren''t going to use DNS to push the
puppet server''s ip, it''s probably not worth the bother. 
It''s just nice to do that because that way you can point the clients
are a different location if you need to.  Often in this situation, you
can''t use puppet to do that, because puppet is broken.


My fault on the logs.  You also need this directory in Ubuntu:
Permissions	User	Group	Location
drwxr-x---	puppet	puppet	/var/log/puppet

I''m guessing that puppet puts the logs there by default, but it might
be a different location since we aren''t using the same distro and
package.


If the server certificate has the wrong common name, you shouldn''t need
to touch the clients.  I think you could fix it by following these steps.  I
have not tested this.  If you attempt it, make sure you have a very good backup.
I only think this *should* work.

service puppetmaster stop
rm /var/lib/puppet/ssl/certs/{Server Name Here}.pem
rm /var/lib/puppet/ssl/private_keys/{Server Name Here}.pem
Change the common name to what ever you need.
service puppetmaster start

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 21.06.2010 09:26, christopher floess wrote:
>
>
>>
>>> 2. I never really saw where in the documentation puppet.conf file
is
>>> addressed. I’ve seen that it’s pretty well documented, but again,
did
>>> I miss something, especially considering that I have gone through
the
>>> online manifest-writing/language documentation for the past week,
and
>>> through all of the testing, I never once did something to configure
>>> the client nodes. As mentioned above, I simply ran the puppetd
>>> command.
>> The defaults are usally fine, but you milage may vary, depending on 
>> what you want to do (exported resources, puppet dashboard, foreman, 
>> tagmail etc)
>> You may want to look into the options certname, certdnsnames, 
>> confdir, manifestdir, modulepath, manifest, pluginsync, server (this 
>> list is for both server and client)
> Okay, so is puppet.conf for puppetd, puppetmasterd, or all of the 
> puppet components?
>>
>> From my experince I prefer the packages, either source recompiled for 
>> the current distro or from backports. It''s easier to upgrade
IMHO. I
>> usally rebuild the debian packages for ubuntu, as ubuntu lags a 
>> version or 2 behind debian sid/squeeze. I''m guessing
you''re using
>> lenny, since squeeze and sid are somewhat up to date. Anyhow if your 
>> system is not using packages it is probably easier without packages, 
>> but you should think if it would not be easier to create a local 
>> repository for your packages and install them via packages.
> Yes, I am using Lenny, and I''ve gone the deb making route before.
I''ll
> consider it again, but since that''s usually a bit of an investment
of
> time, it just seemed like a bit of a detour from getting started with 
> puppet.
Don''t try to do it yourself if it''s already done in sid,
download the
sid package source dpkg-source -x it, and dpkg-buildpackage -b ;) Most 
of the time it works, but there are some casese where this doesn''t work
(newer debuilder, newer build libs etc)
>
> Unfortunately, we''ve just had to put forth a real effort to try to
not
> use any of the standard Debian ruby stuff. The interpreter and a 
> handful of gems is fine, but then everything else, we install 
> ourselves. Actually at this point we''ve also abandoned the
interpreter
> in favor or Ruby enterprise, but that''s another thread :)
>
> Thanks for the feedback.
>
> Regards,
> Chris
>
>
Silviu

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Okay, I got pulled away from this for a few days, but I just wanted to 
follow up on it, since I have everything resolved now. Thanks for your 
help everyone. I''ve been hanging out in the channel, and I''m
still
developing the puppet configuration, so I''m sure you''ll hear
from me in
some way in the near future.
> Because you don''t want to re-setup the clients, or because
you''re
> worried about breaking it?  Actually, the certificate might already 
> have "puppet" and "puppet.bestgroup" as aliases.
Because I was wet behind the ears and didn''t know better :)

The certificate only works for puppet.bestgroup, but once I got into 
actually using puppet.conf, it was resolved without any problems. I 
don''t have control of the dns, and in fact, the only node that
doesn''t
have have a fqdn is the puppetmasterd (we''re managing set of servers
for
a client. In the end, there will be 6 or 7 all together, but our private 
nodes will also be managed by puppet). For those of you who are new and 
have a similar problem, here is the relevant line in my puppet.conf

[puppetd]
     # The server to which server puppetd should connect
     # The default value is ''puppet''.
     # server = puppet
     server = servercharlie.bestgroup

This is actually the only value that that I changed from the default.
> On the other hand, I was assuming you control DNS for all the clients 
> in one or two central locations.  If you aren''t going to use DNS
to
> push the puppet server''s ip, it''s probably not worth the
bother.  It''s
> just nice to do that because that way you can point the clients are a 
> different location if you need to.  Often in this situation, you
can''t
> use puppet to do that, because puppet is broken.
>
>
> My fault on the logs.  You also need this directory in Ubuntu:
> Permissions User Group Location
> drwxr-x--- puppet puppet /var/log/puppet
>
> I''m guessing that puppet puts the logs there by default, but it
might
> be a different location since we aren''t using the same distro and
package.
Actually in my case, this wasn''t true. I did have masterhttp.log there,
but that was the only one. The other ones all logged to syslog. puppet 
--genconfig indicates that /var/lib/puppet/log is the default location 
for (I think) all of the other facilities, but like I said, I only have 
one log file in that directory.

I imagine that it has something to do with log settings, which I
haven''t
really looked into any more because the syslog logging was sufficient 
and I haven''t run into any more problems.
> If the server certificate has the wrong common name, you shouldn''t
> need to touch the clients.  I think you could fix it by following 
> these steps. *I have not tested this.  If you attempt it, make sure 
> you have a very good backup.  I only think this *should* work.*
>
> service puppetmaster stop
> rm /var/lib/puppet/ssl/certs/{Server Name Here}.pem
> rm /var/lib/puppet/ssl/private_keys/{Server Name Here}.pem
> Change the common name to what ever you need.
> service puppetmaster start
I removed the entire /etc/puppet/ssl directory after removing the above 
mentioned .pem files yielded an error message. I should have kept the 
message so that I can post it here for reference. Sorry. I just felt 
bold enough, after having worked with this stuff a little  longer, to:

1. Just throw the directories away,:
2.Restart puppetd on all nodes, restart puppetmasterd. This regenerates 
all certificates of all associated parties. What a great feature, 
certificates, and CAs and signing have always just been something for 
which I''ve never thoroughly gotten an understanding.
3. On master re-run ''puppetca --sign
name.of.nodes.certificate''

Regards,
Chris
>
> -- 
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.