Puppet users - Feb 2011 - any workarond recommendation for bug #3910 ?

Would anyone share workaround for the bug in the subject.
(http://projects.puppetlabs.com/issues/3910)
Apologizes if that has been answered, I couldn’t find anything ant
it’s a real show-stopper for our planning.
Thank you

Best Regards,
Stefan

-- 
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 Feb 24, 4:53 am, Stefan Baryakov <stefan.barya...@gmail.com>
wrote:
> Would anyone share workaround for the bug in the subject.
> (http://projects.puppetlabs.com/issues/3910)
> Apologizes if that has been answered, I couldn’t find anything ant
> it’s a real show-stopper for our planning.
That bug arises when client and server disagree about which
environment the client should be in, which can happen (as I understand
it) only when the client specifies a non-default environment to the
server, and the server gets a different environment for the node from
an external node classifier.

It seems to me, then, that the available workarounds are:

1) Do not have clients specify their environments, or

2) Do not have an external node classifier specify the environment (at
least for nodes that should be allowed to specify their own).

What you cannot do is have clients specify their own environments when
an external node classifier on the server specifies different
environments for them.

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 Thu, Feb 24, 2011 at 02:53, Stefan Baryakov
<stefan.baryakov@gmail.com> wrote:
> Would anyone share workaround for the bug in the subject.
> (http://projects.puppetlabs.com/issues/3910)
> Apologizes if that has been answered, I couldn’t find anything ant
> it’s a real show-stopper for our planning.
> Thank you
Make your puppet.conf on the client a template, for which the content
is sent down as part of the manifest rather than fetched later.  You
can set the environment in there, which will be picked up from the
ENC, and will make the *next* run work right. :(

Alternately, Luke Kaines has been prototyping a static compiler; you
can see that here: https://github.com/lak/puppet-static-compiler

That will compile all "file" references over into static, content
based references at the time the catalog is compiled.  It isn''t
entirely trivial, and is only a prototype, but will solve this problem
in the longer term.  It might be worth talking about that if you think
it might help meet your needs.

Regards,
    Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

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

jcbollinger wrote:
> That bug arises when client and server disagree about which
> environment the client should be in, which can happen (as I understand
> it) only when the client specifies a non-default environment to the
> server, and the server gets a different environment for the node from
> an external node classifier.
I''m not sure what you mean by a "non-default environment".
If you don''t specify an environment in puppet.conf for the
client, it will ask for the environment named "production"
when talking to the master, but as far as I know, the master
does not treat that particular name differently from any
other way.

> It seems to me, then, that the available workarounds are:
> 1) Do not have clients specify their environments, or
I believe that is not possible.  My understanding is that the
environment name is a mandatory part of each request the client
sends to the master, in the protocol used by 0.25.x and 2.6.x
clients.  You can choose to not specify an environment in the
puppet.conf file of the client, but that''s exactly equivalent
to explicitly specifying "production".

In the protocol used in 0.24 and earlier, the environment was
only sent when requesting the catalog, not when fetching files.
Not that that helped anything, because the master still only ran
the external node classifier for the catalog, so when a client
fetched a file, the master would just guess at what environment
it should look the file up in (and failing in ways that were not
exactly obvious to understand; this broke things even without an
external node classifier trying to override the client''s idea of
environment).


	/Bellman

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

Stefan Baryakov wrote:
> Would anyone share workaround for the bug in the subject.
> (http://projects.puppetlabs.com/issues/3910)
> Apologizes if that has been answered, I couldn’t find anything ant
> it’s a real show-stopper for our planning.
I think not using ''source => "puppet:///..."''
references, but instead
using ''content => file(...)'' or ''content =>
template(...)'' everywhere,
would do the trick.

Except if you have custom facts that differ between environments,
or custom type providers that differ between environments.  Then
you are screwed.


	/Bellman

-- 
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 Thu, Feb 24, 2011 at 1:29 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
> Stefan Baryakov wrote:
>
>> Would anyone share workaround for the bug in the subject.
>> (http://projects.puppetlabs.com/issues/3910)
>> Apologizes if that has been answered, I couldn’t find anything ant
>> it’s a real show-stopper for our planning.
>
> I think not using ''source =>
"puppet:///..."'' references, but instead
> using ''content => file(...)'' or ''content
=> template(...)'' everywhere,
> would do the trick.
Except you end up shipping the file contents *every* time in the
catalog. This kind of sucks.
> Except if you have custom facts that differ between environments,
> or custom type providers that differ between environments.  Then
> you are screwed.
No you''re not? If you''re using modules properly with
environments, the
facts/types/providers are all pluginsync''d from the lib/ subdirectory
contents of all the modules in your environment.

The facts have no bearing on specifying content instead of source.

-- 
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 wrote:
> On Thu, Feb 24, 2011 at 1:29 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
>> I think not using ''source =>
"puppet:///..."'' references, but instead
>> using ''content => file(...)'' or ''content
=> template(...)'' everywhere,
>> would do the trick.
> Except you end up shipping the file contents *every* time in the
> catalog. This kind of sucks.
Well, you got to pick your poison: either that, or risk a (possibly
compromised and malicious) client managing to trick the master into
giving out information from an environment that client should not
get information from.

>> Except if you have custom facts that differ between environments,
>> or custom type providers that differ between environments.  Then
>> you are screwed.
> No you''re not? If you''re using modules properly with
environments, the
> facts/types/providers are all pluginsync''d from the lib/
subdirectory
> contents of all the modules in your environment.
Of all the modules in the environment the *client* asks for.  Not
the environment the external node classifier says the client should
be provided from.  The master does not run the classifier when the
client requests to download plugins, and thus cannot override the
environment the client specifies.

Or are the file requests for downloading plugins different from
other file requests, so they *do* trigger the external classifier?
I''ll admit that I haven''t actually tested this or looked at
what
the code does in this case, but I haven''t gotten the impression
it *is* run in that case.
> The facts have no bearing on specifying content instead of source.
Exactly.  Using content=> instead of source=> is not a workaround
for bug 3910 when dealing with per-environment plugins.  So if you
*do* have different plugins in different environments, and those
contain secrets the wrong client must not know, then I believe you
*are* screwed, because I don''t think there is any workaround for
that.  (Except actually fixing bug 3910 properly, by running the
external node classifier for each and every client request...)

Am I missing something?


	/Bellman

-- 
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 wrote:
> On Thu, Feb 24, 2011 at 1:29 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
>> I think not using ''source =>
"puppet:///..."'' references, but instead
>> using ''content => file(...)'' or ''content
=> template(...)'' everywhere,
>> would do the trick.
> 
> Except you end up shipping the file contents *every* time in the
> catalog. This kind of sucks.
On the flip side, that should save you on roundtrips, right?
At a guess, it would be a loss performance wise if you have
a few large files, fast CPU:s for checksumming, low bandwidth
and low latency between client and master, but a win if you
have many small files, high bandwidth and high latency.


	/Bellman

-- 
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 Thu, Feb 24, 2011 at 3:05 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
> Nigel Kersten wrote:
>
>> On Thu, Feb 24, 2011 at 1:29 PM, Thomas Bellman
<bellman@nsc.liu.se>
>> wrote:
>
>>> I think not using ''source =>
"puppet:///..."'' references, but instead
>>> using ''content => file(...)'' or
''content => template(...)'' everywhere,
>>> would do the trick.
>
>> Except you end up shipping the file contents *every* time in the
>> catalog. This kind of sucks.
>
> Well, you got to pick your poison: either that, or risk a (possibly
> compromised and malicious) client managing to trick the master into
> giving out information from an environment that client should not
> get information from.
Yep. The inefficiency in sending all files every time is why Luke''s
been working on the static compiler stuff, which is looking really
quite awesome.

>>> Except if you have custom facts that differ between environments,
>>> or custom type providers that differ between environments.  Then
>>> you are screwed.
>
>> No you''re not? If you''re using modules properly with
environments, the
>> facts/types/providers are all pluginsync''d from the lib/
subdirectory
>> contents of all the modules in your environment.
>
> Of all the modules in the environment the *client* asks for.  Not
> the environment the external node classifier says the client should
> be provided from.  The master does not run the classifier when the
> client requests to download plugins, and thus cannot override the
> environment the client specifies.
Oh sure. I missed your context somehow. I currently consider it broken
to even try setting the environment from the ENC. You have to rely
upon the client.

> Or are the file requests for downloading plugins different from
> other file requests, so they *do* trigger the external classifier?
> I''ll admit that I haven''t actually tested this or looked
at what
> the code does in this case, but I haven''t gotten the impression
> it *is* run in that case.
>
>> The facts have no bearing on specifying content instead of source.
>
> Exactly.  Using content=> instead of source=> is not a workaround
> for bug 3910 when dealing with per-environment plugins.  So if you
> *do* have different plugins in different environments, and those
> contain secrets the wrong client must not know, then I believe you
> *are* screwed, because I don''t think there is any workaround for
> that.  (Except actually fixing bug 3910 properly, by running the
> external node classifier for each and every client request...)
>
> Am I missing something?
No, I think we were just talking about different aspects of this thread.

Do you really have "secrets" in your plugins though? That feels like a
design smell somehow.

-- 
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 2011-02-25 00:23, Nigel Kersten wrote:
> On Thu, Feb 24, 2011 at 3:05 PM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
>> So if you
>> *do* have different plugins in different environments, and those
>> contain secrets the wrong client must not know, then I believe you
>> *are* screwed, because I don''t think there is any workaround
for
>> that.  (Except actually fixing bug 3910 properly, by running the
>> external node classifier for each and every client request...)
>> Am I missing something?
> No, I think we were just talking about different aspects of this thread.
> Do you really have "secrets" in your plugins though? That feels
like a
> design smell somehow.
*I* don''t.  Anything that I can''t publish for the entire world
goes
into a file-server module named "private", which serves host specific
files, including various passwords and private keys.

But I can''t vouch for what anyone else does.  And it depends on what
your standards for what should be kept secret is.  For example, any
plugin that is not super-trivial is likely protected by copyright, and
you might not have the license to show that to all your clients.

Also, specialized facts, types, providers and functions can reveal
things about your, or your clients'', organizations.  If you have a
plugin for managing ACME bluetooth-controlled explosive tennis balls,
then someone seeing that plugin might A) guess that Wile E Coyote is
another of your clients, and B) suspect that Mr. Coyote is planning
to use that kind of device.

Just the information about which companies one has business dealings
with is considered sensitive information by some.


	/Bellman

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