Issue #13284 has been updated by Chris Price. Status changed from Accepted to Investigating
I'm in the midst of investigating this. One question that comes to mind: Do we envision that providers would want/need to be able to specify the environment variables on a per-execution basis? Or only on a per-command basis? In other words... would it be sufficient to allow the provider to register the desired environment variables at roughly the same time they are registering the command itself? And then, all subsequent executions of those commands would use the defined set of environment variables? Or, does the provider need to be able to specify the environment vars at the time that it requests individual executions of the command? The former appears to present fewer implementation obstacles but is slightly less flexible. Perhaps a middle ground would be to require the environment vars to be registered at the time that the command was registered, but to allow the registration to accept ruby blocks which could be treated as callbacks for each subsequent execution of the command. ---------------------------------------- Bug #13284: MacPorts provider needs to set HOME while running `port` command. https://projects.puppetlabs.com/issues/13284#change-57840 Author: Daniel Pittman Status: Investigating Priority: Normal Assignee: Chris Price Category: executables Target version: Telly Affected Puppet version: development Keywords: Branch: In [commit e44a8abd7dc7b2cac4c05eb7a50b53bdd71a1cbc][commit] the `HOME`, `USER`, and `LOGNAME` environment variables were set to be removed by default during the execution of external commands. This is generally a good idea, because those are inherited by default from the user who Puppet starts running as, and can be quite misleading if we change user ID - as we commonly do to execute external commands, and on the master. One limitation of this is that the MacPorts provider needs to set HOME to something during invocation, or we run into the error: 1) Package provider macports should be able to get a list of existing packages Failure/Error: provider.instances.each do |package| Puppet::ExecutionFailure: Execution of '/opt/local/bin/port -q installed' returned 1: usage: cut -b list [-n] [file ...] cut -c list [file ...] cut -f list [-s] [-d delim] [file ...] while executing "exec dscl -q . -read /Users/[exec id -un] NFSHomeDirectory | cut -d ' ' -f 2" (procedure "mportinit" line 95) invoked from within "mportinit ui_options global_options global_variations" Error: /opt/local/bin/port: Failed to initialize MacPorts, usage: cut -b list [-n] [file ...] cut -c list [file ...] cut -f list [-s] [-d delim] [file ...] # ./lib/puppet/util/execution.rb:135:in `execute' # ./lib/puppet/util.rb:476:in `execute' # ./lib/puppet/provider.rb:122:in `port' # ./lib/puppet/provider/package/macports.rb:49:in `instances' # ./spec/integration/provider/package_spec.rb:37 Setting `HOME` to `/opt/local` is a good choice, especially since the MacPorts provider only supports the default install location by design. Unfortunately, the `commands` mechanism that is part of the provider interface doesn't allow access to the environment - which it should, since this will not be the final command to require that treatment. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
