Puppet 3 killed my environment variables

[Daniele Sluijters]

Hello,

In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER and $LOGNAME environment variables are unset and nowhere to be found. I realise this change was necessary because it caused some weird start-up issues with Puppet but this also killed our RabbitMQ module.

RabbitMQ is written in Erlang and that thing _requires_ a $HOME to be set as it will try to write an erlang-cookie to it and horribly fail and go up in flames if it can't. Since Puppet 3 every Exec we have in the RabbitMQ module now fails because of this. We've tried changing the command to '$HOME=/var/lib/misc/puppet rabbitmqctl <do something>' but yet again the Exec type just nukes the environment too. This being the 'offending' pull request which got merged: https://github.com/puppetlabs/puppet/commit/14670c5850462472f5efcfc6ea11d2b4cab708a7

So, short of patching Puppet to not do this or generate static wrappers for every rabbitmqctl command which then in turn get called by an Exec, how do we solve this? I really don't feel like generating wrappers for every Exec that needs one of those environment variables set. I'd actually expect that Exec would allow me to explicitly pass in environment variables that I really need set in that case but the docs don't seem to know anything about that.

Kind regards,

-- 

Daniele Sluijters

[Stephen Gran]

Hi,

Can you not just set resource defaults like:

Exec {
environment => "HOME=/home/wibble"
}

?

Cheers,
--
Stephen Gran
Senior Systems Integrator - The Guardian

Please consider the environment before printing this email.
------------------------------------------------------------------
Visit guardian.co.uk - newspaper of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad

Save up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.
Visit guardian.co.uk/subscribe

---------------------------------------------------------------------
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP

Registered in England Number 908396

[Daniele Sluijters]

Hi,

Sorry, I got confused between two things. It's not the actual Exec type. it's when a provider executes a command that the environment cannot be set.

-- 

Daniele Sluijters

[jcbollinger]

On Wednesday, October 3, 2012 8:11:55 AM UTC-5, Daniele Sluijters wrote:

Hi,

Sorry, I got confused between two things. It's not the actual Exec type. it's when a provider executes a command that the environment cannot be set.

Puppet's guts have code for setting a custom environment for commands, but the 'command' and 'commands' functions don't provide an interface to it.  I'm working from the code here, not actual experience, but it looks like you can use the has_command() function instead, something like:

has_command(:my_command, '/usr/sbin') do
  environment({ 'HOME' => '/some/homedir' })
end

I don't remember seeing that documented anywhere, so it probably qualifies as an internal interface -- use at your own risk.  Since you'll probably want to look at the code yourself, you can find that function in puppet/lib/puppet/provider.rb.  In particular, you can examine how it is used by the documented 'command' and 'commands' functions.


John

[Andy Parker]

On Thu, Oct 4, 2012 at 7:24 AM, jcbollinger <John.Bo...@stjude.org> wrote:
>
>
> Puppet's guts have code for setting a custom environment for commands, but
> the 'command' and 'commands' functions don't provide an interface to it.
> I'm working from the code here, not actual experience, but it looks like you
> can use the has_command() function instead, something like:
>
> has_command(:my_command, '/usr/sbin') do
> environment({ 'HOME' => '/some/homedir' })
> end
>
> I don't remember seeing that documented anywhere, so it probably qualifies
> as an internal interface -- use at your own risk. Since you'll probably
> want to look at the code yourself, you can find that function in
> puppet/lib/puppet/provider.rb. In particular, you can examine how it is
> used by the documented 'command' and 'commands' functions.
>

It is an oversight that that isn't documented. That should be
considered public interface and the way to solve this.

I've filed https://projects.puppetlabs.com/issues/16779 to get this in the docs.

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

[Jeff McCune]

On Wed, Oct 3, 2012 at 5:45 AM, Daniele Sluijters
<daniele....@gmail.com> wrote:
> Hello,
>
> In Puppet 3 Puppet does its absolute best to make sure $HOME, $USER and
> $LOGNAME environment variables are unset and nowhere to be found. I realise
> this change was necessary because it caused some weird start-up issues with
> Puppet but this also killed our RabbitMQ module.

This shouldn't be the case. Puppet should respect the values of
environment variables. A related change that I'm aware of is that
Puppet goes out of the way to ensure HOME is _set_ rather than unset.

Could you refer me to the information you found that indicates this
change of unsetting HOME USER and LOGNAME is necessary? I'm not sure
I'm up to speed on this information and would like to review it.

Thanks,
-Jeff

[jwkoelewijn]

Thanks for this suggestion,

this did the trick!

Kind regards,

J.W. Koelewijn