FAQ
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

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

Search Discussions

  • Stephen Gran at Oct 3, 2012 at 1:00 pm
    Hi,
    On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters 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.


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

    --
    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.
  • Daniele Sluijters at Oct 3, 2012 at 1:11 pm
    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
    On Wednesday, 3 October 2012 15:00:54 UTC+2, Stephen Gran wrote:

    Hi,
    On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters 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.


    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.
    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
    --
    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/-/ghtP6bqOcegJ.
    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 at Oct 4, 2012 at 2:24 pm

    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

    --
    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-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.
  • Andy Parker at Oct 4, 2012 at 4:39 pm

    On Thu, Oct 4, 2012 at 7:24 AM, jcbollinger 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-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.
  • Jwkoelewijn at Oct 8, 2012 at 11:49 am
    Thanks for this suggestion,

    this did the trick!

    Kind regards,

    J.W. Koelewijn
    On Thursday, October 4, 2012 4:24:26 PM UTC+2, jcbollinger wrote:


    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
    --
    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/-/gQ524gd_QzwJ.
    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.
  • Hawk Kroeger at Oct 9, 2012 at 8:38 pm
    Hey jwkoelewijn, do you mind posting your solution for the rabbitmq
    provider.

    Thanks!
    On Monday, 8 October 2012 04:18:42 UTC-7, jwkoelewijn wrote:

    Thanks for this suggestion,

    this did the trick!

    Kind regards,

    J.W. Koelewijn
    On Thursday, October 4, 2012 4:24:26 PM UTC+2, jcbollinger wrote:


    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
    --
    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/-/FhtxtSinbo4J.
    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.
  • Jwkoelewijn at Oct 3, 2012 at 1:26 pm
    Hi Stephen,

    You are right about the exec command being able to receive an environment
    hash. This, however, does not solve our problem, because this is not
    possible when creating a new Puppet Type and Provider. In the provider
    commands are created using the "commands <name> => 'system_command' " class
    level method. Whenever a command is to be executed by the provider, this
    command is executed _without_ the USER, HOME and LOGNAME variables. There
    does not seem to be a method to pass environment variables from within a
    provider...

    Best regards,

    Jan-Willem Koelewijn
    On Wednesday, October 3, 2012 3:00:54 PM UTC+2, Stephen Gran wrote:

    Hi,
    On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters 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.


    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.
    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
    --
    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/-/_Ud91jE-FMAJ.
    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.
  • David Carr at Oct 3, 2012 at 1:51 pm
    Within a provider, I think you can use this syntax:

    has_command(:port, "/opt/local/bin/port") do
    environment :HOME => "/opt/local"
    end


    http://www.mail-archive.com/puppet-dev@googlegroups.com/msg17373.html

    On Wednesday, October 3, 2012 9:11:03 AM UTC-4, jwkoelewijn wrote:

    Hi Stephen,

    You are right about the exec command being able to receive an environment
    hash. This, however, does not solve our problem, because this is not
    possible when creating a new Puppet Type and Provider. In the provider
    commands are created using the "commands <name> => 'system_command' " class
    level method. Whenever a command is to be executed by the provider, this
    command is executed _without_ the USER, HOME and LOGNAME variables. There
    does not seem to be a method to pass environment variables from within a
    provider...

    Best regards,

    Jan-Willem Koelewijn
    On Wednesday, October 3, 2012 3:00:54 PM UTC+2, Stephen Gran wrote:

    Hi,
    On Wed, 2012-10-03 at 05:45 -0700, Daniele Sluijters 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.


    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.
    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
    --
    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/-/90rD99fFEWwJ.
    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.
  • Jeff McCune at Oct 4, 2012 at 4:52 pm

    On Wed, Oct 3, 2012 at 5:45 AM, Daniele Sluijters 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

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 3, '12 at 12:45p
activeOct 9, '12 at 8:38p
posts10
users8
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase