Puppet users - Jul 2010 - exec not finding shell builtins/functions?

Hello,

We''re running 2.6 on Ubuntu 10.04 and here''s what I''m
seeing (simplified test):

class cdtest {
  exec {''cdtest'': command => ''cd'' }
}

# puppet agent --test
info: Caching catalog for servername
info: Applying configuration version ''1280441519''
err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0 failed:
Could not find command ''cd''
notice: Finished catalog run in 0.65 seconds
#

Any ideas on why this is failing? I am running into this with rvm as well (since
it is a function and not a binary).

Thanks!

Greg Graf
Systems Engineer
Rackspace



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is
prohibited.
If you receive this transmission in error, please notify us immediately by
e-mail
at abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.

-- 
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, Jul 29, 2010 at 3:23 PM, Greg Graf <greg.graf@rackspace.com>
wrote:
> Hello,
>
> We''re running 2.6 on Ubuntu 10.04 and here''s what
I''m seeing (simplified test):
>
> class cdtest {
>  exec {''cdtest'': command => ''cd'' }
> }
>
> # puppet agent --test
> info: Caching catalog for servername
> info: Applying configuration version ''1280441519''
> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0
failed: Could not find command ''cd''
> notice: Finished catalog run in 0.65 seconds
> #
>
> Any ideas on why this is failing? I am running into this with rvm as well
(since it is a function and not a binary).
I saw the same thing happen with a few for-loops and had to wrap them
up in /bin/sh -c ''...'' for 2.6.  Now that I look for it, I
can''t find
anything about this behavior change in the release notes for 2.6.  Was
it coincidental that it ever worked?

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

Greg Graf said:
> Hello,
> 
> We''re running 2.6 on Ubuntu 10.04 and here''s what
I''m seeing (simplified test):
> 
> class cdtest {
>   exec {''cdtest'': command => ''cd'' }
> }
> 
> # puppet agent --test
> info: Caching catalog for servername
> info: Applying configuration version ''1280441519''
> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0
failed: Could not find command ''cd''
> notice: Finished catalog run in 0.65 seconds
> #
> 
> Any ideas on why this is failing? I am running into this with rvm as well
(since it is a function and not a binary).
> 
Isn''t this by design?  Unless the puppet docs say that "exec"
is always
run through a shell, then I wouldn''t expect it to be.

In my manifests, if I want a shell, I explicitly use:

 command => ''/bin/sh -c "some shell commands"''
-- 
Rohan McGovern
QA Engineer
Qt Development Frameworks, Nokia

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

Richard Crowley wrote:
> On Thu, Jul 29, 2010 at 3:23 PM, Greg Graf <greg.graf@rackspace.com>
wrote:
>> Hello,
>>
>> We''re running 2.6 on Ubuntu 10.04 and here''s what
I''m seeing (simplified test):
>>
>> class cdtest {
>>  exec {''cdtest'': command => ''cd''
}
>> }
>>
>> # puppet agent --test
>> info: Caching catalog for servername
>> info: Applying configuration version ''1280441519''
>> err: /Stage[main]/Cdtest/Exec[cdtest]/returns: change from notrun to 0
failed: Could not find command ''cd''
>> notice: Finished catalog run in 0.65 seconds
>> #
>>
>> Any ideas on why this is failing? I am running into this with rvm as
well (since it is a function and not a binary).
> 
> I saw the same thing happen with a few for-loops and had to wrap them
> up in /bin/sh -c ''...'' for 2.6.  Now that I look for it,
I can''t find
> anything about this behavior change in the release notes for 2.6.  Was
> it coincidental that it ever worked?
> 
See:

http://projects.puppetlabs.com/issues/4288
http://projects.puppetlabs.com/issues/4299

For some history and comments on this.  We''d welcome some input into
what you think should be safe and expected behaviour here.

Cheers

James Turnbull

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

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

James Turnbull <james@puppetlabs.com> writes:
> Richard Crowley wrote:
>> On Thu, Jul 29, 2010 at 3:23 PM, Greg Graf
<greg.graf@rackspace.com> wrote:
[...]
>> I saw the same thing happen with a few for-loops and had to wrap them
>> up in /bin/sh -c ''...'' for 2.6.  Now that I look for
it, I can''t find
>> anything about this behavior change in the release notes for 2.6.  Was
>> it coincidental that it ever worked?
>
> See:
>
> http://projects.puppetlabs.com/issues/4288
> http://projects.puppetlabs.com/issues/4299
>
> For some history and comments on this.  We''d welcome some input
into
> what you think should be safe and expected behaviour here.
If this is a "voting" matter, let me put in a vote for passing a
simple string
to the shell, and passing an array direct to exec, which is consistent with
the use of ''system'' style commands in a whole bunch of
sysadmin scripting
languages.

Eg, this:

   exec { "foo": command => [''/bin/ls'',
''|'' ''foo''] }

will pass ''|'' ''foo'' to the ls command,
compared to:

   exec { "foo": command => "/bin/ls | foo" }

...which passes it to the default system shell.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ 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.

+1

On 7/30/2010 6:18 AM, Daniel Pittman wrote:
> James Turnbull<james@puppetlabs.com>  writes:
>> Richard Crowley wrote:
>>> On Thu, Jul 29, 2010 at 3:23 PM, Greg
Graf<greg.graf@rackspace.com>  wrote:
>
> [...]
>
>>> I saw the same thing happen with a few for-loops and had to wrap
them
>>> up in /bin/sh -c ''...'' for 2.6.  Now that I look
for it, I can''t find
>>> anything about this behavior change in the release notes for 2.6. 
Was
>>> it coincidental that it ever worked?
>>
>> See:
>>
>> http://projects.puppetlabs.com/issues/4288
>> http://projects.puppetlabs.com/issues/4299
>>
>> For some history and comments on this.  We''d welcome some
input into
>> what you think should be safe and expected behaviour here.
>
> If this is a "voting" matter, let me put in a vote for passing a
simple string
> to the shell, and passing an array direct to exec, which is consistent with
> the use of ''system'' style commands in a whole bunch of
sysadmin scripting
> languages.
>
> Eg, this:
>
>     exec { "foo": command =>  [''/bin/ls'',
''|'' ''foo''] }
>
> will pass ''|'' ''foo'' to the ls command,
compared to:
>
>     exec { "foo": command =>  "/bin/ls | foo" }
>
> ...which passes it to the default system shell.
>
>          Daniel

-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

-- 
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, 30 Jul 2010, Daniel Pittman wrote:
> Eg, this:
> 
>    exec { "foo": command => [''/bin/ls'',
''|'', ''foo''] }
> 
> will pass ''|'' ''foo'' to the ls command,
compared to:
> 
>    exec { "foo": command => "/bin/ls | foo" }
> 
> ...which passes it to the default system shell.
+1  [I added a missing comma above.]

--apb (Alan Barrett)

-- 
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 2010-07-30 06:18, Daniel Pittman wrote:
> If this is a "voting" matter, let me put in a vote for passing a
simple string
> to the shell, and passing an array direct to exec, which is consistent with
> the use of ''system'' style commands in a whole bunch of
sysadmin scripting
> languages.
> 
> Eg, this:
> 
>    exec { "foo": command => [''/bin/ls'',
''|'' ''foo''] }
> 
> will pass ''|'' ''foo'' to the ls command,
compared to:
> 
>    exec { "foo": command => "/bin/ls | foo" }
> 
> ...which passes it to the default system shell.
I think this is a very reasonable suggestion, so +1 from me as well.

But I''d like to point out the shellquote() function, which can give you
the semantics of the first version already today:

    exec { "foo": command => shellquote("/bin/ls",
"|", "foo"); }

(There''s actually a slight difference.  Using shellquote() today will
give you an intermediate shell process, making it somewhat less efficient.)


	/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 07/30/2010 12:18 AM, Daniel Pittman wrote:
> James Turnbull<james@puppetlabs.com>  writes:
>    
>> Richard Crowley wrote:
>>      
>>> On Thu, Jul 29, 2010 at 3:23 PM, Greg
Graf<greg.graf@rackspace.com>  wrote:
>>>        
> [...]
>
>    
>>> I saw the same thing happen with a few for-loops and had to wrap
them
>>> up in /bin/sh -c ''...'' for 2.6.  Now that I look
for it, I can''t find
>>> anything about this behavior change in the release notes for 2.6. 
Was
>>> it coincidental that it ever worked?
>>>        
>> See:
>>
>> http://projects.puppetlabs.com/issues/4288
>> http://projects.puppetlabs.com/issues/4299
>>
>> For some history and comments on this.  We''d welcome some
input into
>> what you think should be safe and expected behaviour here.
>>      
> If this is a "voting" matter, let me put in a vote for passing a
simple string
> to the shell, and passing an array direct to exec, which is consistent with
> the use of ''system'' style commands in a whole bunch of
sysadmin scripting
> languages.
>
> Eg, this:
>
>     exec { "foo": command =>  [''/bin/ls'',
''|'' ''foo''] }
>
> will pass ''|'' ''foo'' to the ls command,
compared to:
>
>     exec { "foo": command =>  "/bin/ls | foo" }
>
> ...which passes it to the default system shell.
>
>          Daniel
>    
That seems like the implementation would be tricky and error-prone, 
compared to having people add sh/bash/ksh -c to the beginning of the 
command in the exec. I mean, is that really such a big deal?

-- 
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
"When the going gets weird, the weird turn pro."

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

+1

On Fri, Jul 30, 2010 at 10:07 AM, Joe McDonagh
<joseph.e.mcdonagh@gmail.com>wrote:
> On 07/30/2010 12:18 AM, Daniel Pittman wrote:
>
>> James Turnbull<james@puppetlabs.com>  writes:
>>
>>
>>> Richard Crowley wrote:
>>>
>>>
>>>> On Thu, Jul 29, 2010 at 3:23 PM, Greg
Graf<greg.graf@rackspace.com>
>>>>  wrote:
>>>>
>>>>
>>> [...]
>>
>>
>>
>>> I saw the same thing happen with a few for-loops and had to wrap
them
>>>> up in /bin/sh -c ''...'' for 2.6.  Now that I
look for it, I can''t find
>>>> anything about this behavior change in the release notes for
2.6.  Was
>>>> it coincidental that it ever worked?
>>>>
>>>>
>>> See:
>>>
>>> http://projects.puppetlabs.com/issues/4288
>>> http://projects.puppetlabs.com/issues/4299
>>>
>>> For some history and comments on this.  We''d welcome some
input into
>>> what you think should be safe and expected behaviour here.
>>>
>>>
>> If this is a "voting" matter, let me put in a vote for
passing a simple
>> string
>> to the shell, and passing an array direct to exec, which is consistent
>> with
>> the use of ''system'' style commands in a whole bunch
of sysadmin scripting
>> languages.
>>
>> Eg, this:
>>
>>    exec { "foo": command =>  [''/bin/ls'',
''|'' ''foo''] }
>>
>> will pass ''|'' ''foo'' to the ls
command, compared to:
>>
>>    exec { "foo": command =>  "/bin/ls | foo" }
>>
>> ...which passes it to the default system shell.
>>
>>         Daniel
>>
>>
> That seems like the implementation would be tricky and error-prone,
> compared to having people add sh/bash/ksh -c to the beginning of the
command
> in the exec. I mean, is that really such a big deal?
>
> --
> Joe McDonagh
> AIM: YoosingYoonickz
> IRC: joe-mac on freenode
> "When the going gets weird, the weird turn pro."
>
>
> --
> 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.

Daniel

Any chance you could throw your solution on the ticket and I''ll start a
discussion about it internally.

Thanks

James

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
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, 30 Jul 2010, Joe McDonagh wrote:
> >If this is a "voting" matter, let me put in a vote for
passing a
> >simple string to the shell, and passing an array direct to exec
>
> That seems like the implementation would be tricky and error-prone,
> compared to having people add sh/bash/ksh -c to the beginning of the
> command in the exec. I mean, is that really such a big deal?
Most of the work is already done by ruby''s Kernel.exec() function;
puppet would simply need the ability to pass an array all the way
through to the underlying ruby function.

--apb (Alan Barrett)

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

James Turnbull <james@puppetlabs.com> writes:
> Any chance you could throw your solution on the ticket and I''ll
start a
> discussion about it internally.
Um, sure.  Let me go dig out the details (eg: ticket url) and all.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ 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.