ENC - what does 'error 1' mean?

[JonY]

Im recoding an ENC in ruby (from Perl). The new version gives me the error:

Oct 30 18:03:25 serv puppet-master[29051]: Failed when searching for node nodexx: Failed to find nodexx via exec: Execution of '<path-to-enc> nodexx' returned 1:

What I've checked:

- both can be run under the 'puppet' account ("sudo -u puppet <path-to-enc>" )

- both return (seemingly) identical YAML

- both are 'chmod puppet:puppet <file>'

But only the perl works... what did I miss?

[Felix Frank]

Well, obviously your script is throwing an error when invoked from
Puppet, behaving differently than from the command line.

This can have numerous reasons related to your process environment.
Perhaps the master is running with a different Ruby (PE?)

To debug this, add early debug logging to your ENC script and trace its
execution when Puppet calls it. If you fail to generate *any* log
output, this likely means that Ruby won't even start interpreting your code.

HTH,
Felix

[JonY]

I've simplified the script to this:

#!/usr/local/bin/ruby

open('test.out', 'w') { |f|

  f.puts "Hello"

}

.. and it still gives me 'error 1' when run as an ENC. 

While it's true that the puppet server is using ruby 1.8.7 this shouldn't matter for the above code. 

What would the effect of outputting incorrect YAML be? I'm wondering about the syntax of what's being printed.

[Felix Frank]

On 10/31/2014 11:35 AM, JonY wrote:
> I've simplified the script to this:
>
> #!/usr/local/bin/ruby
>
> open('test.out', 'w') { |f|
> f.puts "Hello"
> }

Well, writing to a relative file path is bound to be potentially
problematic.

> .. and it still gives me 'error 1' when run as an ENC.

No, it states that 'the script returned 1'. Which is weird, yes.

> While it's true that the puppet server is using ruby 1.8.7 this
> shouldn't matter for the above code.

Right.

> What would the effect of outputting incorrect YAML be? I'm wondering
> about the syntax of what's being printed.

I disbelieve that the content of stdout is the issue. The Ruby process
exits with a non-zero status, meaning that something goes wrong.

Can you wrap the Ruby in a shell script and tee its output somewhere?

#!/bin/bash
/path/to/ruby-enc 2>&1 | tee /tmp/enc-output

Configure that scriptlet as your ENC script and see what ends up in the
file.

BTW, rereading your first mail - I don't think puppet should own the
script. That's just horrible security. It should have permission to
execute it, but only root (or a privileged user account) should be able
to write it. Unless I'm missing something about ENC theory (never used
those).

HTH,
Felix

[jcbollinger]

On Friday, October 31, 2014 8:02:33 AM UTC-5, Felix.Frank wrote:

On 10/31/2014 11:35 AM, JonY wrote:
> I've simplified the script to this:
>
> #!/usr/local/bin/ruby
>
> open('test.out', 'w') { |f|
>   f.puts "Hello"
> }

Well, writing to a relative file path is bound to be potentially
problematic.

In particular, if the working directory is not writable by puppet (which it shouldn't be), or if there is already a file in it of the specified name, and that isn't writable by puppet (which it shouldn't be), then the open() will fail.  I don't know off-hand what exit code Ruby returns when a top-scope statement throws an exception, but my first guess would be 1.

 

> .. and it still gives me 'error 1' when run as an ENC.

No, it states that 'the script returned 1'. Which is weird, yes.

Maybe.  I also don't know what exit code ruby yields when a script completes normally.  It should exit 0, and net sources claim it does, but it's worth verifying that.

 

> What would the effect of outputting incorrect YAML be? I'm wondering
> about the syntax of what's being printed.

I disbelieve that the content of stdout is the issue. The Ruby process
exits with a non-zero status, meaning that something goes wrong.

Agreed.

 

Can you wrap the Ruby in a shell script and tee its output somewhere?

#!/bin/bash
/path/to/ruby-enc 2>&1 | tee /tmp/enc-output

Configure that scriptlet as your ENC script and see what ends up in the
file.

Good idea.

 

BTW, rereading your first mail - I don't think puppet should own the
script. That's just horrible security. It should have permission to
execute it, but only root (or a privileged user account) should be able
to write it. Unless I'm missing something about ENC theory (never used
those).

I don't claim to be an expert on ENC theory (and doesn't that sound highbrow ;-) ), but I agree that the master should not have write permission on the ENC script.


John