Questions about 1.4.3-rc1

[Hasan]

Hi Greg,

As offered, but somewhat belatedly, I have been playing with 1.4.3-rc1.

I created two scripts (attached to this post).  The first calls the second passing a secure option.

I have a few of observations about these, in the form of questions here, rather than bug reports in lighthouse, because I'm unsure whether they show intended functionality or not.

1. If I run the first script I get the expected functionality: both scripts execute "sudo pwd" and return the right result, with the bad password in the 2nd script overwritten, as expected, by the correct one from the 1st script.
2. If I switch "Input Type" from "Secure Remote Authentication" to just "Secure", it fails to pass the value to sudo.  I suppose this is for kinds of required passwords other than sudo.  Is that the intended behavior?
   
3. If I try to use the "Secure Remote Authentication" input type on the local node (not dispatched to a remote node), the supplied sudo password is not used.  Instead, the sudo password request appears in the console window where I launched RunDeck (with java -jar rundeck-launcher-1.4.3-rc1.jar), obliging me to enter it again, even though provided in the job.  In my opinion this is a bug.
4. If the 2nd job indicates a different remote node from the 1st job, it dispatches to it in any case, rather than working on the same target node as the caller job.  I mention this as a feature request, as described below.
   

In my opinion caller jobs should have a switch that permits them to override the target node specification of the called jobs, such that all called jobs operate on the same target as the original calling job.  It is really tedious to have to go keep track of all subsidiary jobs and manually change their targets one by one each time I want to work on a different target node.

But that would be only a partial solution.  I don't recall whether this has already been requested, but I would like to see a complete separation between jobs and their target nodes, using something you might call a "Duty Roster" table.  When calling a job I would like to be able to pass it a "Duty Name" argument.  The duty name would identify a unique item in the duty roster containing all your usual dispatch options.  Those options would be used uniformly by the top-level job and all its subsidiary jobs.

Rgds,
Hasan

[Greg Schueler]

Hi Hasan, thanks for trying the RC, I'll respond inline below:

On Fri, May 25, 2012 at 6:04 AM, Hasan <martinh...@gmail.com> wrote:
> Hi Greg,
>
> As offered, but somewhat belatedly, I have been playing with 1.4.3-rc1.
>
> I created two scripts (attached to this post).  The first calls the second
> passing a secure option.
>
> I have a few of observations about these, in the form of questions here,
> rather than bug reports in lighthouse, because I'm unsure whether they show
> intended functionality or not.
>
> If I run the first script I get the expected functionality: both scripts
> execute "sudo pwd" and return the right result, with the bad password in the
> 2nd script overwritten, as expected, by the correct one from the 1st script.
> If I switch "Input Type" from "Secure Remote Authentication" to just
> "Secure", it fails to pass the value to sudo.  I suppose this is for kinds
> of required passwords other than sudo.  Is that the intended behavior?

Yes this is the intended behavior: only "Secure Remote Authentication"
options can be used for authentication (SSH or sudo), to prevent them
from being inadvertently exposed in scripts or commands.

"Secure" options allow you to have some of the same security
enhancements (value is not stored in DB, password field used for
input), but still use the value in scripts or commands (for example,
you need to provide a database password to load SQL data, but don't
want that password stored or shown in the Rundeck GUI)

> If I try to use the "Secure Remote Authentication" input type on the local
> node (not dispatched to a remote node), the supplied sudo password is not
> used.  Instead, the sudo password request appears in the console window
> where I launched RunDeck (with java -jar rundeck-launcher-1.4.3-rc1.jar),
> obliging me to enter it again, even though provided in the job.  In my
> opinion this is a bug.

This is a (known) issue: "local" executor doesn't support Sudo:
http://rundeck.lighthouseapp.com/projects/59277/tickets/534-sudo-authority-on-localhost

Currently only the built-in SSH node executor supports Secure Remote
Authentication options, and uses it for SSH and/or remote Sudo
executions over SSH.

> If the 2nd job indicates a different remote node from the 1st job, it
> dispatches to it in any case, rather than working on the same target node as
> the caller job.  I mention this as a feature request, as described below.
>
> In my opinion caller jobs should have a switch that permits them to override
> the target node specification of the called jobs, such that all called jobs
> operate on the same target as the original calling job.  It is really
> tedious to have to go keep track of all subsidiary jobs and manually change
> their targets one by one each time I want to work on a different target
> node.
>
> But that would be only a partial solution.  I don't recall whether this has
> already been requested, but I would like to see a complete separation
> between jobs and their target nodes, using something you might call a "Duty
> Roster" table.  When calling a job I would like to be able to pass it a
> "Duty Name" argument.  The duty name would identify a unique item in the
> duty roster containing all your usual dispatch options.  Those options would
> be used uniformly by the top-level job and all its subsidiary jobs.

This is actually something we plan to do eventually, separate Node
filters/sets from Jobs:
http://rundeck.lighthouseapp.com/projects/59277/tickets/484-decouple-jobs-from-workflows-and-nodesets

>
> Rgds,
> Hasan
>

Thanks!

[Hasan]

This is actually something we plan to do eventually, separate Node filters/sets from Jobs:
http://rundeck.lighthouseapp.com/projects/59277/tickets/484-decouple-jobs-from-workflows-and-nodesets

Oh right, I remember reading that discussion now.   I'd be very pleased to see fixes to both   484-decouple-jobs-from-workflows-and-nodesets    and    534-sudo-authority-on-localhost   get into this new release.

Any chance of that?