Puppet users - Dec 2008 - Puppet Client Isolated from Network

I am reviewing puppet for suitability on a project that I''m working
on.  In many regards, it looks perfect and I''m very pleased with the
overall feel thus far.  For a proof-of-concept example, I''ve created a
manifest that ensures that the ntp package is installed on the client,
that it has the correct ntp.conf and that the services is running with
that config.  So far so good.

The clients are going to be PC/104 systems running the Fedora
"appliance" OS from CompactFlash more or less as if it were a live CD
(think compressed and read-only).  The goal is to have this OS be just
the bare bones plus the puppet client.  On boot, the puppet client
would install the required packages, configure them and start services
and custom applications as
necessary.  This means that any disk updates occurring after boot will
not persist through a reboot.  Boot times are longer this way, but the
systems remain very flexible and can be deployed for a variety of
purposes, which would ultimately be dictated by the puppet master.

If there is a network loss for whatever reason, it is required that
system remain operational in all other regards.  If the network outage
occurs after boot up this is rather trivial to handle.  However, if
the system is rebooted after loss of network, it must proceed under
the last known state of configuration.  I''ve been partly successful in
this regard by creating a 2nd file system on the CompactFlash to
which /var/cache/yum is sym-linked.  This in effect makes the yum
cache persistent through reboots.

With the network disconnected, I can remove the ntp package and its
configuration file from the client, reboot and puppet will dutifully
reinstall the ntp package.  However it is unable to retrieve the
configuration file from the puppet master and thus far I have not
found any way to configure puppetd to maintain a locally cached
version to use as a fail safe.  I have experimented with ignorecache
and usecacheonfailure but without success.  Do I need to make each
puppet client its own file server somehow with a synchronized copy of
the master?  Is there some better route I''ve missed?

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

I am reviewing puppet for suitability on a project that I''m working
on.  In many regards, it looks perfect and I''m very pleased with the
overall feel thus far.  For a proof-of-concept example, I''ve created a
manifest that ensures that the ntp package is installed on the client,
that it has the correct ntp.conf and that the services is running with
that config.  So far so good.

The clients are going to be PC/104 systems running the Fedora
"appliance" OS from CompactFlash more or less as if it were a live CD
(think compressed and read-only).  The goal is to have this OS be just
the bare bones plus the puppet client.  On boot, the puppet client
would install the required packages, configure them and start services
and custom applications as
necessary.  This means that any disk updates occurring after boot will
not persist through a reboot.  Boot times are longer this way, but the
systems remain very flexible and can be deployed for a variety of
purposes, which would ultimately be dictated by the puppet master.

If there is a network loss for whatever reason, it is required that
system remain operational in all other regards.  If the network outage
occurs after boot up this is rather trivial to handle.  However, if
the system is rebooted after loss of network, it must proceed under
the last known state of configuration.  I''ve been partly successful in
this regard by creating a 2nd file system on the CompactFlash to
which /var/cache/yum is sym-linked.  This in effect makes the yum
cache persistent through reboots.

With the network disconnected, I can remove the ntp package and its
configuration file from the client, reboot and puppet will dutifully
reinstall the ntp package.  However it is unable to retrieve the
configuration file from the puppet master and thus far I have not
found any way to configure puppetd to maintain a locally cached
version to use as a fail safe.  I have experimented with ignorecache
and usecacheonfailure but without success.  Do I need to make each
puppet client its own file server somehow with a synchronized copy of
the master?  Is there some other route I''ve missed?

I''ve also noted that the ntp daemon does not start in this case, but
I''m pretty sure that''s simply because puppetd knows a
dependency
hasn''t yet been met.  If I can just convince puppetd to somehow
persist/cache (similar to what I did with yum) the config file and use
that if all else fails, I''ll be ready to roll on this project.

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

I''ve been pushing forward on this and have made much progress in
having a puppet client continue to do its thing from the last known
good state after becoming disconnected from the network.

I''ve reached a major stumbling block though.  If the network interface
had been up and operational, but is now failing (e.g., cable
unplugged), puppet can continue on despite a few warnings in the
logs.  However, if the interface hasn''t even been configured (e.g.,
booting with cable unplugged), puppet seems to take a different route
and just refuses to push-on-regardless.  It just continues to log the
following every few minutes:

err: Could not call puppetca.getcert: #<Errno::ENETENREACH: Network is
unreachable --connect(2)>
err: Could not request certificate: Certificate retrieval failed:
Network is unreachable --connect(2)

I really need for puppet to simply continue with whatever state and
configuration details it has cached from the last successful run.  Any
ideas how I might achieve this?


On Dec 8, 2:14 pm, John Florian <john.flor...@dart.biz>
wrote:
> I am reviewing puppet for suitability on a project that I''m
working
> on.  In many regards, it looks perfect and I''m very pleased with
the
> overall feel thus far.  For a proof-of-concept example, I''ve
created a
> manifest that ensures that the ntp package is installed on the client,
> that it has the correct ntp.conf and that the services is running with
> that config.  So far so good.
>
> The clients are going to be PC/104 systems running the Fedora
> "appliance" OS from CompactFlash more or less as if it were a
live CD
> (think compressed and read-only).  The goal is to have this OS be just
> the bare bones plus the puppet client.  On boot, the puppet client
> would install the required packages, configure them and start services
> and custom applications as
> necessary.  This means that any disk updates occurring after boot will
> not persist through a reboot.  Boot times are longer this way, but the
> systems remain very flexible and can be deployed for a variety of
> purposes, which would ultimately be dictated by the puppet master.
>
> If there is a network loss for whatever reason, it is required that
> system remain operational in all other regards.  If the network outage
> occurs after boot up this is rather trivial to handle.  However, if
> the system is rebooted after loss of network, it must proceed under
> the last known state of configuration.  I''ve been partly
successful in
> this regard by creating a 2nd file system on the CompactFlash to
> which /var/cache/yum is sym-linked.  This in effect makes the yum
> cache persistent through reboots.
>
> With the network disconnected, I can remove the ntp package and its
> configuration file from the client, reboot and puppet will dutifully
> reinstall the ntp package.  However it is unable to retrieve the
> configuration file from the puppet master and thus far I have not
> found any way to configure puppetd to maintain a locally cached
> version to use as a fail safe.  I have experimented with ignorecache
> and usecacheonfailure but without success.  Do I need to make each
> puppet client its own file server somehow with a synchronized copy of
> the master?  Is there some other route I''ve missed?
>
> I''ve also noted that the ntp daemon does not start in this case,
but
> I''m pretty sure that''s simply because puppetd knows a
dependency
> hasn''t yet been met.  If I can just convince puppetd to somehow
> persist/cache (similar to what I did with yum) the config file and use
> that if all else fails, I''ll be ready to roll on this project.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Have you thought about side-stepping puppetd/puppetmasterd and just  
writing your manifests to use puppet stand alone?

Adam

On Dec 12, 2008, at 6:30 AM, John Florian wrote:
>
> I''ve been pushing forward on this and have made much progress in
> having a puppet client continue to do its thing from the last known
> good state after becoming disconnected from the network.
>
> I''ve reached a major stumbling block though.  If the network
interface
> had been up and operational, but is now failing (e.g., cable
> unplugged), puppet can continue on despite a few warnings in the
> logs.  However, if the interface hasn''t even been configured
(e.g.,
> booting with cable unplugged), puppet seems to take a different route
> and just refuses to push-on-regardless.  It just continues to log the
> following every few minutes:
>
> err: Could not call puppetca.getcert: #<Errno::ENETENREACH: Network is
> unreachable --connect(2)>
> err: Could not request certificate: Certificate retrieval failed:
> Network is unreachable --connect(2)
>
> I really need for puppet to simply continue with whatever state and
> configuration details it has cached from the last successful run.  Any
> ideas how I might achieve this?
>
>
> On Dec 8, 2:14 pm, John Florian <john.flor...@dart.biz> wrote:
>> I am reviewing puppet for suitability on a project that I''m
working
>> on.  In many regards, it looks perfect and I''m very pleased
with the
>> overall feel thus far.  For a proof-of-concept example, I''ve  
>> created a
>> manifest that ensures that the ntp package is installed on the  
>> client,
>> that it has the correct ntp.conf and that the services is running  
>> with
>> that config.  So far so good.
>>
>> The clients are going to be PC/104 systems running the Fedora
>> "appliance" OS from CompactFlash more or less as if it were a
live CD
>> (think compressed and read-only).  The goal is to have this OS be  
>> just
>> the bare bones plus the puppet client.  On boot, the puppet client
>> would install the required packages, configure them and start  
>> services
>> and custom applications as
>> necessary.  This means that any disk updates occurring after boot  
>> will
>> not persist through a reboot.  Boot times are longer this way, but  
>> the
>> systems remain very flexible and can be deployed for a variety of
>> purposes, which would ultimately be dictated by the puppet master.
>>
>> If there is a network loss for whatever reason, it is required that
>> system remain operational in all other regards.  If the network  
>> outage
>> occurs after boot up this is rather trivial to handle.  However, if
>> the system is rebooted after loss of network, it must proceed under
>> the last known state of configuration.  I''ve been partly
successful
>> in
>> this regard by creating a 2nd file system on the CompactFlash to
>> which /var/cache/yum is sym-linked.  This in effect makes the yum
>> cache persistent through reboots.
>>
>> With the network disconnected, I can remove the ntp package and its
>> configuration file from the client, reboot and puppet will dutifully
>> reinstall the ntp package.  However it is unable to retrieve the
>> configuration file from the puppet master and thus far I have not
>> found any way to configure puppetd to maintain a locally cached
>> version to use as a fail safe.  I have experimented with ignorecache
>> and usecacheonfailure but without success.  Do I need to make each
>> puppet client its own file server somehow with a synchronized copy of
>> the master?  Is there some other route I''ve missed?
>>
>> I''ve also noted that the ntp daemon does not start in this
case, but
>> I''m pretty sure that''s simply because puppetd knows a
dependency
>> hasn''t yet been met.  If I can just convince puppetd to
somehow
>> persist/cache (similar to what I did with yum) the config file and  
>> use
>> that if all else fails, I''ll be ready to roll on this project.
> >

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

Funny.  I was nearly about to give up hope and then that very thought
occurred to me a bit after posting my last message.  When I had
initially read the docs, I kind of got the impression that was meant
more for debugging only.  As it turns out, it looks to be absolutely
perfect for the task.  I have one puppet exec that basically looks
like this:

  exec { "offline-files":
    command => "rsync -a masterhost:/mastershare/  /offlinefiles;
true"
  }

Of course, the host is preloaded with SSH keys to allow rsync to work
w/o any passphrase.  This brings across all my manifests, classes, and
other support files to an area on CompactFlash so it becomes non-
volatile to the client.  I had to trick puppet through the use of true
in the command because I want puppet to believe this exec always
succeeds.  I''d rather it run with old files than to not run at all.


Anyway, thanks for the tip.  Had my posts not been delayed due to
moderation of new group members, you''d have saved me lots of grief.


On Dec 12, 1:24 pm, Adam Jacob <a...@hjksolutions.com>
wrote:
> Have you thought about side-stepping puppetd/puppetmasterd and just  
> writing your manifests to use puppet stand alone?
>
> Adam
--~--~---------~--~----~------------~-------~--~----~
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 could also keep all your puppet code in a git or svn repository.   
Then you could have a single resource in the puppetmaster that ensures  
the client has the latest revision of the code.  Then you can easily  
isolate the necessary puppet code for a client.  It only updates when  
there''s a new commit and everything is stored locally on the clients.

On Dec 12, 2008, at 12:41 PM, John Florian wrote:
>
> Funny.  I was nearly about to give up hope and then that very thought
> occurred to me a bit after posting my last message.  When I had
> initially read the docs, I kind of got the impression that was meant
> more for debugging only.  As it turns out, it looks to be absolutely
> perfect for the task.  I have one puppet exec that basically looks
> like this:
>
>  exec { "offline-files":
>    command => "rsync -a masterhost:/mastershare/  /offlinefiles;
> true"
>  }
>
> Of course, the host is preloaded with SSH keys to allow rsync to work
> w/o any passphrase.  This brings across all my manifests, classes, and
> other support files to an area on CompactFlash so it becomes non-
> volatile to the client.  I had to trick puppet through the use of true
> in the command because I want puppet to believe this exec always
> succeeds.  I''d rather it run with old files than to not run at
all.
>
>
> Anyway, thanks for the tip.  Had my posts not been delayed due to
> moderation of new group members, you''d have saved me lots of
grief.
>
>
> On Dec 12, 1:24 pm, Adam Jacob <a...@hjksolutions.com> wrote:
>> Have you thought about side-stepping puppetd/puppetmasterd and just
>> writing your manifests to use puppet stand alone?
>>
>> Adam
>
> >

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