Project

General

Profile

Feature #12489

Expose effective user in the foreman server

Added by Ivan Necas over 6 years ago. Updated about 4 years ago.


Description

As an Foreman user, I want to be able to determine what effective user should be used for the
execution, based on host params. The effective user is enforced by using su/sudo on the managed host.


Related issues

Has duplicate Foreman Remote Execution - Feature #13184: Remote Execution needs ability to restrict commands on a per user basisDuplicate2016-01-13

Associated revisions

Revision e06a27d9 (diff)
Added by Ivan Necas over 6 years ago

Refs #12489 - enable sudo

Revision 10195630
Added by Ivan Necas over 6 years ago

Merge pull request #16 from iNecas/sudo

Refs #12489 - enable sudo

Revision 7c949a4d (diff)
Added by Ivan Necas over 6 years ago

Fixes #12489 - Effective user support

Allow to specify effective user settings on template and job invocation level.

On job template, on chooses:

value - what effective user value should be used (defaults to
Settings[:remote_executioneffective_user]
current_user - the current user login will be used as the effective user
overridable - the user can change the effective user value at invocation
time - when false, the current user value is enforced

There are two methods of effective user supported now - su and sudo. It's
determined by host param remote_execution_effective_user_method and the default
is configured in settings.

Also, the UI and API job invocation composers are refactored and unified
to reduce the duplicity of code, when adding the effective user on both sides.
It is also preparation for the developer API feature, where we will need also
to compose the job invocation.

Revision 7025de11
Added by Ivan Necas over 6 years ago

Merge pull request #80 from iNecas/effective_user

Fixes #12489 - Effective user support

Revision 3e198c34 (diff)
Added by Ivan Necas over 6 years ago

Refs #12489 - fix accepting triggering options from UI

Revision 1b80fec5
Added by Ivan Necas over 6 years ago

Merge pull request #83 from iNecas/fix-triggering

Refs #12489 - fix accepting triggering options from UI

History

#1 Updated by Ivan Necas over 6 years ago

  • Status changed from New to Assigned
  • Assignee set to Ivan Necas

#2 Updated by Stephen Benjamin over 6 years ago

I was wondering if it shouldn't be at the invocation level? My thinking was maybe a job to perform some postgresql maintenance would be run under postgres, but another job to install some packages would be root.

#3 Updated by Ivan Necas over 6 years ago

Definitely the job template needs to have the last word on the strategy, but multiple strategies will need to be in place.
I was thinking about an erb template for this value, quite smilar to other input types.

#4 Updated by Stephen Benjamin over 6 years ago

Ah I see, that sounds good then

#5 Updated by The Foreman Bot over 6 years ago

  • Status changed from Assigned to Ready For Testing
  • Pull request https://github.com/theforeman/smart_proxy_remote_execution_ssh/pull/16 added

#6 Updated by The Foreman Bot over 6 years ago

  • Pull request https://github.com/theforeman/foreman_remote_execution/pull/80 added

#7 Updated by Ivan Necas over 6 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#8 Updated by The Foreman Bot over 6 years ago

  • Pull request https://github.com/theforeman/foreman_remote_execution/pull/83 added

#9 Updated by Marek Hulán over 6 years ago

  • Legacy Backlogs Release (now unused) set to 108

#10 Updated by Stephen Benjamin over 6 years ago

  • Has duplicate Feature #13184: Remote Execution needs ability to restrict commands on a per user basis added

Also available in: Atom PDF