Puppet users - May 2011 - Should puppet manage its own client configs?

Hi,

Is there a general feel on whether puppet should look after its own
client configuration files and service status? I''d not foresee problems
about a "service ensure enabled" for puppetd and a file object for the
puppet.conf but clearly wouldn''t want to risk locking ourselves out of
the
clients from a bad config file being sent down etc.

Thanks

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,

We have configured puppet to manage its own puppet.conf on clients, and 
to ensure that puppetd is running on all hosts. However it does not 
manage puppet.conf on the puppetmaster, so if we accidentally mess up 
the config, we won''t break the puppetmaster.

The hostname of the puppetmaster is hard-coded, in our case. Can anyone 
think of a better way of identifying the puppetmaster, so our manifests 
will run anywhere, if we decide to make a different machine the 
puppetmaster?

Cheers,
Jonathan

----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------


On 05/16/2011 05:09 PM, Chris Phillips wrote:
> Hi,
>
> Is there a general feel on whether puppet should look after its own
> client configuration files and service status? I''d not foresee
problems
> about a "service ensure enabled" for puppetd and a file object
for the
> puppet.conf but clearly wouldn''t want to risk locking ourselves
out of
> the clients from a bad config file being sent down etc.
>
> Thanks
>
> 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.

On Mon, May 16, 2011 at 3:14 PM, Jonathan Gazeley
<jonathan.gazeley@bristol.ac.uk> wrote:
> The hostname of the puppetmaster is hard-coded, in our case. Can anyone
> think of a better way of identifying the puppetmaster, so our manifests
will
> run anywhere, if we decide to make a different machine the puppetmaster?
I just refer to the puppetmaster as ''puppet'' everywhere and
drop an
entry in /etc/hosts for it.  Then if I wanted to migrate off a server,
I would just hardcode away $servername and $serverip on the old
puppetmaster to point to the new one, and copy the certs over.

node default {
    case $fqdn {
        /puppetmaster/: {
            host { puppet:
                host_aliases => [ "localhost.localdomain",
"puppet" ],
                ip           => "127.0.0.1",
                name         => "localhost",
            }
        }
        default: {
            host { puppet:
                host_aliases => $servername,
                ip           => $serverip,
                name         => "puppet",
           }
        }
    }
}

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

On 16 May 2011 20:14, Jonathan Gazeley
<jonathan.gazeley@bristol.ac.uk>wrote:
> Hi Chris,
>
> We have configured puppet to manage its own puppet.conf on clients, and to
> ensure that puppetd is running on all hosts. However it does not manage
> puppet.conf on the puppetmaster, so if we accidentally mess up the config,
> we won''t break the puppetmaster.
>
This seems a logical thing to do to me, I''ll want to be able to turn on
archive_files sometimes, that''s one angle I''m keen on. Would
be useful to
separate the server and client config files though really, then it
wouldn''t
be irresponsible to manage the client side of the master server separately.

> The hostname of the puppetmaster is hard-coded, in our case. Can anyone
> think of a better way of identifying the puppetmaster, so our manifests
will
> run anywhere, if we decide to make a different machine the puppetmaster?
>
> Well yeah, just make puppet a cname and set the certificate name used on
the master part of puppet.conf correctly. for this side of things, the
client config is totally default, and it just goes to "puppet" via
DNS,
works perfectly, and I can easily rebuild a server an point the puppet cname
to hit it. zero config on that side.

Cheers

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 16 May 2011 20:26, Adam Heinz <amh@metricwise.net> wrote:

I just refer to the puppetmaster as ''puppet'' everywhere and
drop an
> entry in /etc/hosts for it.  Then if I wanted to migrate off a server,
> I would just hardcode away $servername and $serverip on the old
> puppetmaster to point to the new one, and copy the certs over.
>
> node default {
>    case $fqdn {
>        /puppetmaster/: {
>            host { puppet:
>                host_aliases => [ "localhost.localdomain",
"puppet" ],
>                ip           => "127.0.0.1",
>                name         => "localhost",
>            }
>        }
>        default: {
>            host { puppet:
>                host_aliases => $servername,
>                ip           => $serverip,
>                name         => "puppet",
>           }
>        }
>    }
> }
>
Why the distinction between the two? What''s wrong with using a LAN IP
on the
puppetmaster machine as well? To me that''s much clearer that misusing
loopback.

Thanks

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 Mon, May 16, 2011 at 4:08 PM, Chris Phillips <chris@untrepid.com>
wrote:
> Why the distinction between the two? What''s wrong with using a LAN
IP on the
> puppetmaster machine as well? To me that''s much clearer that
misusing
> loopback.
I seem to recall doing that to allow a newly provisioned puppetmaster
to bootstrap itself using puppet (instead of puppetd) and $servername
and $serverip are not available for that initial run.

-- 
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 16 May 2011 21:05, Chris Phillips <chris@untrepid.com> wrote:
>
>
> On 16 May 2011 20:14, Jonathan Gazeley
<jonathan.gazeley@bristol.ac.uk>wrote:
>
>> Hi Chris,
>>
>> We have configured puppet to manage its own puppet.conf on clients, and
to
>> ensure that puppetd is running on all hosts. However it does not manage
>> puppet.conf on the puppetmaster, so if we accidentally mess up the
config,
>> we won''t break the puppetmaster.
>>
>
> This seems a logical thing to do to me, I''ll want to be able to
turn on
> archive_files sometimes, that''s one angle I''m keen on.
Would be useful to
> separate the server and client config files though really, then it
wouldn''t
> be irresponsible to manage the client side of the master server separately.
>
>
Following on from this, if I do change puppet.conf and have a service
subscription against it, should I be able to abort the rest of the run as
puppet needs to reload? Or preferably restart and being the run again
automatically? I''d like to ensure all clients report and all files are
archived for a few months to be safe, and would like to be able to get this
happening by pulling down the puppet.conf (so obviously not archive that
specific file, but that''s no problem) and restarting (or whatever is
technically required to activate the changes. I see a restat become
"scheduled" not actually restaring the service.

Thanks

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 05/16/2011 09:14 PM, Jonathan Gazeley wrote:
> We have configured puppet to manage its own puppet.conf on clients, and
> to ensure that puppetd is running on all hosts.
Hi,

maybe I''m being dense, but this doesn''t address the original
issue, does it?

If you manage to deploy an utterly broken config, puppet won''t be able
to get itself back up to speed because it cannot start anymore.

Am I missing something here?

Cheers,
Felix

-- 
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 24/05/11 11:24, Felix Frank wrote:
> On 05/16/2011 09:14 PM, Jonathan Gazeley wrote:
>> We have configured puppet to manage its own puppet.conf on clients, and
>> to ensure that puppetd is running on all hosts.
>
> Hi,
>
> maybe I''m being dense, but this doesn''t address the
original issue, does it?
>
> If you manage to deploy an utterly broken config, puppet won''t be
able
> to get itself back up to speed because it cannot start anymore.
>
> Am I missing something here?
No, you are correct. If I deploy a garbage config, it will break the 
puppet clients. But the benefit is that I can easily deploy a modified 
puppet config to many clients if we need to add extra config parameters 
in future.

I can mitigate the risk by carefully testing the new puppet.conf on an 
isolated dev machine.

Cheers,
Jonathan

>
> Cheers,
> Felix
>

-- 
----------------------------
Jonathan Gazeley
Network Specialist
Residential & Mobile IT
IT Services
University of Bristol
----------------------------

-- 
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 05/24/2011 12:29 PM, Jonathan Gazeley wrote:
>> If you manage to deploy an utterly broken config, puppet won''t
be able
>> to get itself back up to speed because it cannot start anymore.
>>
>> Am I missing something here?
> 
> No, you are correct. If I deploy a garbage config, it will break the
> puppet clients. But the benefit is that I can easily deploy a modified
> puppet config to many clients if we need to add extra config parameters
> in future.
> 
> I can mitigate the risk by carefully testing the new puppet.conf on an
> isolated dev machine.
That''s an utter relief.

I''ve deployed a mechanism that will deploy a puppet.conf alongside the
actual one and notify a script that becomes active after the catalog run
proper.
It activates the new config, but if puppet is found to not run correctly
afterwards, the original config is restored instead.

Cheers,
Felix

-- 
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.

Felix,

Would you mind sharing how you implemented the process to restart
Puppet after an update?

Thanks,

John

On May 24, 6:34 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 05/24/2011 12:29 PM, Jonathan Gazeley wrote:
>
> >> If youmanageto deploy an utterly broken
config,puppetwon''t be able
> >> to get itself back up to speed because it cannot start anymore.
>
> >> Am I missing something here?
>
> > No, you are correct. If I deploy a garbage config, it will break the
> >puppetclients. But the benefit is that I can easily deploy a modified
> >puppetconfig to many clients if we need to add extra config parameters
> > in future.
>
> > I can mitigate the risk by carefully testing the newpuppet.conf on an
> > isolated dev machine.
>
> That''s an utter relief.
>
> I''ve deployed a mechanism that will deploy apuppet.conf alongside
the
> actual one and notify a script that becomes active after the catalog run
> proper.
> It activates the new config, but ifpuppetis found to not run correctly
> afterwards, the original config is restored instead.
>
> Cheers,
> Felix
-- 
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.