Puppet users - Dec 2010 - File not found during puppet fileserving

Here is the error I get:

err: //.../File[/root/.bash_profile]: Failed to retrieve current state
of resource: Could not retrieve information from source(s)
puppet:///modules/bash/bash_profile at ...

However, the file is there:

# ll /usr/share/puppet/development/app_modules/bash/files/bash_profile
-rw-r--r-- 1 root root 402 Nov 24 05:52 /usr/share/puppet/development/
app_modules/bash/files/bash_profile

Here is my modulepath for my development environment:

modulepath = /usr/share/puppet/development/app_modules:/usr/share/
puppet/development/hosttype_modules:/usr/share/puppet/development/
other_modules

The modulepath is working fine, but I am wondering if it is impacting
the lookup for the file serving stuff.  I tried finding where the
puppetmaster actually looks for the file but got lost in all the
puppet code.  Thanks.

-eric

-- 
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 Dec 6, 2010, at 12:54 PM, Eric Snow wrote:
> Here is the error I get:
> 
> err: //.../File[/root/.bash_profile]: Failed to retrieve current state
> of resource: Could not retrieve information from source(s)
> puppet:///modules/bash/bash_profile at ...
> 
> However, the file is there:
> 
> # ll /usr/share/puppet/development/app_modules/bash/files/bash_profile
> -rw-r--r-- 1 root root 402 Nov 24 05:52 /usr/share/puppet/development/
> app_modules/bash/files/bash_profile
> 
> Here is my modulepath for my development environment:
> 
> modulepath = /usr/share/puppet/development/app_modules:/usr/share/
> puppet/development/hosttype_modules:/usr/share/puppet/development/
> other_modules
> 
> The modulepath is working fine, but I am wondering if it is impacting
> the lookup for the file serving stuff.  I tried finding where the
> puppetmaster actually looks for the file but got lost in all the
> puppet code.  Thanks.
I''ve seen this error is the user puppet can''t read
/usr/share/puppet/development/app_modules/bash/files/bash_profile because of
permissions on folders in the path.

Are "bash" and "files" one of these? (Or something more
permissive)

-rwxr-x--- 1 root puppet
-rwxr-xr-x 1 root root

-- 
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 Dec 6, 2:54 pm, Eric Snow <es...@verio.net>
wrote:
> Here is the error I get:
>
> err: //.../File[/root/.bash_profile]: Failed to retrieve current state
> of resource: Could not retrieve information from source(s)
> puppet:///modules/bash/bash_profile at ...
>
> However, the file is there:
>
> # ll /usr/share/puppet/development/app_modules/bash/files/bash_profile
> -rw-r--r-- 1 root root 402 Nov 24 05:52 /usr/share/puppet/development/
> app_modules/bash/files/bash_profile
>
> Here is my modulepath for my development environment:
>
> modulepath = /usr/share/puppet/development/app_modules:/usr/share/
> puppet/development/hosttype_modules:/usr/share/puppet/development/
> other_modules
>
> The modulepath is working fine, but I am wondering if it is impacting
> the lookup for the file serving stuff.  I tried finding where the
> puppetmaster actually looks for the file but got lost in all the
> puppet code.  Thanks.
Try changing the URL to this:

puppet:///bash/bash_profile

That is, drop the "modules" part of the path.

You can read that URL as something like: file "bash_profile" from the
"bash" module, located on the Puppet server from which the current
catalog was obtained.  File names are relative to the "files"
subdirectory of the named module, so it looks like you have the file
itself in the right place.

As Patrick pointed out, the file *and all directories in the path to
it* do need to be readable by the puppetmaster process, and the
directories need to be executable by it.


Cheers,

John

-- 
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, Dec 06, 2010 at 01:54:40PM -0800, jcbollinger
wrote:
> Try changing the URL to this:
> 
> puppet:///bash/bash_profile
> 
> That is, drop the "modules" part of the path.
> 
Are you sure? IIRC this is deprecated
http://docs.puppetlabs.com/guides/file_serving.html
says that modules has to be in the path

lib/puppet/file_serving/configuration.rb:44 has a deprecation warning
if you do not put modules in your source

-Stefan

I have verified that everything has correct permissions:

# ls -la app_modules/bash/files/
drwxr-xr-x 3 root root 4096 Nov 24 05:52 .
drwxr-xr-x 5 root root 4096 Nov 24 05:52 ..
-rw-r--r-- 1 root root  402 Nov 24 05:52 bash_profile

-eric

On Dec 6, 2:23 pm, Patrick <kc7...@gmail.com>
wrote:
> On Dec 6, 2010, at 12:54 PM, Eric Snow wrote:
>
>
>
>
>
>
>
>
>
> > Here is the error I get:
>
> > err: //.../File[/root/.bash_profile]: Failed to retrieve current state
> > of resource: Could not retrieve information from source(s)
> > puppet:///modules/bash/bash_profile at ...
>
> > However, the file is there:
>
> > # ll /usr/share/puppet/development/app_modules/bash/files/bash_profile
> > -rw-r--r-- 1 root root 402 Nov 24 05:52 /usr/share/puppet/development/
> > app_modules/bash/files/bash_profile
>
> > Here is my modulepath for my development environment:
>
> > modulepath = /usr/share/puppet/development/app_modules:/usr/share/
> > puppet/development/hosttype_modules:/usr/share/puppet/development/
> > other_modules
>
> > The modulepath is working fine, but I am wondering if it is impacting
> > the lookup for the file serving stuff.  I tried finding where the
> > puppetmaster actually looks for the file but got lost in all the
> > puppet code.  Thanks.
>
> I''ve seen this error is the user puppet can''t read
/usr/share/puppet/development/app_modules/bash/files/bash_profile because of
permissions on folders in the path.
>
> Are "bash" and "files" one of these? (Or something more
permissive)
>
> -rwxr-x--- 1 root puppet
> -rwxr-xr-x 1 root root
-- 
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.

Thanks for the feedback.  My understanding is that the first part of
the path has to be the location for the file server to do the lookup
(as in the /etc/puppet/fileserver.conf file).  Without this the
puppetmaster would not know where to look for the files.  Was this
something that works for you?

My real concern is that the fileserver portion of the puppetmaster
code is not properly handling a modulepath with multiple entries.  Any
ideas where I can verify this?  Thanks.

-eric

On Dec 6, 2:54 pm, jcbollinger <John.Bollin...@stJude.org>
wrote:
> On Dec 6, 2:54 pm, Eric Snow <es...@verio.net> wrote:
>
>
>
>
>
>
>
>
>
> > Here is the error I get:
>
> > err: //.../File[/root/.bash_profile]: Failed to retrieve current state
> > of resource: Could not retrieve information from source(s)
> > puppet:///modules/bash/bash_profile at ...
>
> > However, the file is there:
>
> > # ll /usr/share/puppet/development/app_modules/bash/files/bash_profile
> > -rw-r--r-- 1 root root 402 Nov 24 05:52 /usr/share/puppet/development/
> > app_modules/bash/files/bash_profile
>
> > Here is my modulepath for my development environment:
>
> > modulepath = /usr/share/puppet/development/app_modules:/usr/share/
> > puppet/development/hosttype_modules:/usr/share/puppet/development/
> > other_modules
>
> > The modulepath is working fine, but I am wondering if it is impacting
> > the lookup for the file serving stuff.  I tried finding where the
> > puppetmaster actually looks for the file but got lost in all the
> > puppet code.  Thanks.
>
> Try changing the URL to this:
>
> puppet:///bash/bash_profile
>
> That is, drop the "modules" part of the path.
>
> You can read that URL as something like: file "bash_profile" from
the
> "bash" module, located on the Puppet server from which the
current
> catalog was obtained.  File names are relative to the "files"
> subdirectory of the named module, so it looks like you have the file
> itself in the right place.
>
> As Patrick pointed out, the file *and all directories in the path to
> it* do need to be readable by the puppetmaster process, and the
> directories need to be executable by it.
>
> Cheers,
>
> John
-- 
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, Dec 06, 2010 at 03:31:01PM -0800, Eric Snow
wrote:
> Thanks for the feedback.  My understanding is that the first part of
> the path has to be the location for the file server to do the lookup
> (as in the /etc/puppet/fileserver.conf file).  Without this the
> puppetmaster would not know where to look for the files.  Was this
> something that works for you?
> 
> My real concern is that the fileserver portion of the puppetmaster
> code is not properly handling a modulepath with multiple entries.  Any
> ideas where I can verify this?  Thanks.
> 
> -eric
Since the default modulepath has more than one entry
(etc/puppet/modules:/usr/share/puppet/modules) i dont think that puppet
really has a problem with that. But i suggest to remove your
fileserver.conf. Or at least check that you havent overwritten the
modules mount.

-Stefan

Thanks for the reply.  The modules mount is okay:

[modules]
  allow *

I am just trying to track down why the puppetmaster can''t locate the
file in question even though it is there are permissions are okay.
What would be a good place to look in the puppet code to find out what
paths it is actually checking?  Maybe something in modules.rb?
Thanks.

-eric

On Dec 6, 4:45 pm, Stefan Schulte <stefan.schu...@taunusstein.net>
wrote:
> On Mon, Dec 06, 2010 at 03:31:01PM -0800, Eric Snow wrote:
> > Thanks for the feedback.  My understanding is that the first part of
> > the path has to be the location for the file server to do the lookup
> > (as in the /etc/puppet/fileserver.conf file).  Without this the
> > puppetmaster would not know where to look for the files.  Was this
> > something that works for you?
>
> > My real concern is that the fileserver portion of the puppetmaster
> > code is not properly handling a modulepath with multiple entries.  Any
> > ideas where I can verify this?  Thanks.
>
> > -eric
>
> Since the default modulepath has more than one entry
> (etc/puppet/modules:/usr/share/puppet/modules) i dont think that puppet
> really has a problem with that. But i suggest to remove your
> fileserver.conf. Or at least check that you havent overwritten the
> modules mount.
>
> -Stefan
>
>  application_pgp-signature_part
> < 1KViewDownload
-- 
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 Dec 6, 5:21 pm, Stefan Schulte <stefan.schu...@taunusstein.net>
wrote:
> On Mon, Dec 06, 2010 at 01:54:40PM -0800, jcbollinger wrote:
> > Try changing the URL to this:
>
> > puppet:///bash/bash_profile
>
> > That is, drop the "modules" part of the path.
>
> Are you sure? IIRC this is
deprecatedhttp://docs.puppetlabs.com/guides/file_serving.html
> says that modules has to be in the path
>
> lib/puppet/file_serving/configuration.rb:44 has a deprecation warning
> if you do not put modules in your source
I''m sure that it works for me, albeit on 0.24.8.  I''m also
sure that
it''s the form documented with the File type:

class sendmail {
    file { "/etc/mail/sendmail.cf":
        source =. "puppet://<server>/<module>/sendmail.cf"
    }
}

(See http://docs.puppetlabs.com/guides/types/file.html.  I have taken
the liberty of marking up the <server> and <module> portions of the
URL to emphasize that they are not to be taken as literals.)

It''s possible that that form has been deprecated, but it would be a
shame if that were so, as that makes a lot more sense then having to
put some arbitrary portion of the server''s path _to the module_ into
the URL.  The server doesn''t need help finding the module.

Moreover, I think the documentation is a better place to start than
the code.  Sure, it''s great to have the code available if you need it,
but anything you discover in the code can change without notice in a
later version if it is not backed up by documentation.

Besides, changing the URL should be pretty quick and easy to try.


John

-- 
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 Dec 7, 8:11 am, jcbollinger <John.Bollin...@stJude.org>
wrote:
> that makes a lot more sense then having to
> put some arbitrary portion of the server''s path _to the module_
into
> the URL.
But of course, that''s not what the "modules" bit is actually
intended
to mean (sorry).  Obviously, the file serving docs and the File docs
are out of sync.

I still maintain that it would be worthwhile to try the URL form I
suggested, if only because it would be quick and easy to do.  If
Puppet has a bug in resolving the URL to a file name then it might be
that one form works but the other doesn''t.  Additionally, Eric
didn''t
mention which version of Puppet he is using; it may be older than the
first one that implements the /modules mount point.


John

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

Alas, I am running 0.25, and the fileserving mount is a required part
of the path.

-eric

On Dec 7, 7:29 am, jcbollinger <John.Bollin...@stJude.org>
wrote:
> On Dec 7, 8:11 am, jcbollinger <John.Bollin...@stJude.org> wrote:
>
> > that makes a lot more sense then having to
> > put some arbitrary portion of the server''s path _to the
module_ into
> > the URL.
>
> But of course, that''s not what the "modules" bit is
actually intended
> to mean (sorry).  Obviously, the file serving docs and the File docs
> are out of sync.
>
> I still maintain that it would be worthwhile to try the URL form I
> suggested, if only because it would be quick and easy to do.  If
> Puppet has a bug in resolving the URL to a file name then it might be
> that one form works but the other doesn''t.  Additionally, Eric
didn''t
> mention which version of Puppet he is using; it may be older than the
> first one that implements the /modules mount point.
>
> John
-- 
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, Dec 06, 2010 at 03:55:20PM -0800, Eric Snow
wrote:
> Thanks for the reply.  The modules mount is okay:
> 
> [modules]
>   allow *
Although a short test with your snippet in my fileserver.conf worked for me:
can you try again with an empty fileserver.conf?

-Stefan

The issue was that I was not passing the --environment flag during my
puppet run.  Apparently it ignores the environment returned by the
external node classifier.  Thanks for all the feedback.

-eric

On Dec 7, 10:15 am, Stefan Schulte <stefan.schu...@taunusstein.net>
wrote:
> On Mon, Dec 06, 2010 at 03:55:20PM -0800, Eric Snow wrote:
> > Thanks for the reply.  The modules mount is okay:
>
> > [modules]
> >   allow *
>
> Although a short test with your snippet in my fileserver.conf worked for
me:
> can you try again with an empty fileserver.conf?
>
> -Stefan
>
>  application_pgp-signature_part
> < 1KViewDownload
-- 
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 Fri, Dec 10, 2010 at 12:55 PM, Eric Snow <esnow@verio.net>
wrote:
> The issue was that I was not passing the --environment flag during my
> puppet run.  Apparently it ignores the environment returned by the
> external node classifier.  Thanks for all the feedback.
Ahah. I was wondering if you''d perhaps hit that bug.

http://projects.puppetlabs.com/issues/3910

Feel free to watch it to help us prioritize.
>
> -eric
>
> On Dec 7, 10:15 am, Stefan Schulte <stefan.schu...@taunusstein.net>
> wrote:
>> On Mon, Dec 06, 2010 at 03:55:20PM -0800, Eric Snow wrote:
>> > Thanks for the reply.  The modules mount is okay:
>>
>> > [modules]
>> >   allow *
>>
>> Although a short test with your snippet in my fileserver.conf worked
for me:
>> can you try again with an empty fileserver.conf?
>>
>> -Stefan
>>
>>  application_pgp-signature_part
>> < 1KViewDownload
>
> --
> 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.
>
>


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com

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

We have just stumbled across this having moved to external nodes using
Foreman.

Our dev environment is where we make quick changes to manifests (and
nominally only affect dev nodes), but sometimes those changes are only
relevant to production nodes. In those scenarios, on production nodes we
used to run:

puppetd --test --noop --environment=dev

and that would help validate that what we were about to tag would actually
work once it made it to production. Once our dev manifests were correct, we
would make an svn tag and release that to production.

I''ve quickly read through the below bug and I can see good arguments
for and
against client nodes being able to set the environment, so I''m not sure
how
I''d vote.

How are others approaching this scenario or has everyone just managed to
avoid it?

Thanks,

Iain


On 11 December 2010 12:59, Nigel Kersten <nigel@puppetlabs.com> wrote:
> On Fri, Dec 10, 2010 at 12:55 PM, Eric Snow <esnow@verio.net> wrote:
> > The issue was that I was not passing the --environment flag during my
> > puppet run.  Apparently it ignores the environment returned by the
> > external node classifier.  Thanks for all the feedback.
>
> Ahah. I was wondering if you''d perhaps hit that bug.
>
> http://projects.puppetlabs.com/issues/3910
>
> Feel free to watch it to help us prioritize.
>
> >
> > -eric
> >
> > On Dec 7, 10:15 am, Stefan Schulte
<stefan.schu...@taunusstein.net>
> > wrote:
> >> On Mon, Dec 06, 2010 at 03:55:20PM -0800, Eric Snow wrote:
> >> > Thanks for the reply.  The modules mount is okay:
> >>
> >> > [modules]
> >> >   allow *
> >>
> >> Although a short test with your snippet in my fileserver.conf
worked for
> me:
> >> can you try again with an empty fileserver.conf?
> >>
> >> -Stefan
> >>
> >>  application_pgp-signature_part
> >> < 1KViewDownload
> >
> > --
> > 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.
> >
> >
>
>
>
> --
> Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
>
> --
> 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.
>
>
-- 
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.

Client nodes can set the environment, so long as the server doesn''t.
On Dec 14, 2010 3:21 AM, "Iain Sutton" <iainsutton@gmail.com>
wrote:
> We have just stumbled across this having moved to external nodes using
> Foreman.
>
> Our dev environment is where we make quick changes to manifests (and
> nominally only affect dev nodes), but sometimes those changes are only
> relevant to production nodes. In those scenarios, on production nodes we
> used to run:
>
> puppetd --test --noop --environment=dev
>
> and that would help validate that what we were about to tag would actually
> work once it made it to production. Once our dev manifests were correct,
we
> would make an svn tag and release that to production.
>
> I''ve quickly read through the below bug and I can see good
arguments for
and
> against client nodes being able to set the environment, so I''m not
sure
how
> I''d vote.
>
> How are others approaching this scenario or has everyone just managed to
> avoid it?
>
> Thanks,
>
> Iain
>
>
> On 11 December 2010 12:59, Nigel Kersten <nigel@puppetlabs.com>
wrote:
>
>> On Fri, Dec 10, 2010 at 12:55 PM, Eric Snow <esnow@verio.net>
wrote:
>> > The issue was that I was not passing the --environment flag during
my
>> > puppet run. Apparently it ignores the environment returned by the
>> > external node classifier. Thanks for all the feedback.
>>
>> Ahah. I was wondering if you''d perhaps hit that bug.
>>
>> http://projects.puppetlabs.com/issues/3910
>>
>> Feel free to watch it to help us prioritize.
>>
>> >
>> > -eric
>> >
>> > On Dec 7, 10:15 am, Stefan Schulte
<stefan.schu...@taunusstein.net>
>> > wrote:
>> >> On Mon, Dec 06, 2010 at 03:55:20PM -0800, Eric Snow wrote:
>> >> > Thanks for the reply. The modules mount is okay:
>> >>
>> >> > [modules]
>> >> > allow *
>> >>
>> >> Although a short test with your snippet in my fileserver.conf
worked
for
>> me:
>> >> can you try again with an empty fileserver.conf?
>> >>
>> >> -Stefan
>> >>
>> >> application_pgp-signature_part
>> >> < 1KViewDownload
>> >
>> > --
>> > 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>
<puppet-users%2Bunsubscribe@googlegroups.com<puppet-users%252Bunsubscribe@googlegroups.com>
>
>> .
>> > For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>> >
>> >
>>
>>
>>
>> --
>> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
>>
>> --
>> 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>
<puppet-users%2Bunsubscribe@googlegroups.com<puppet-users%252Bunsubscribe@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<puppet-users%2Bunsubscribe@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.