-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #34812 - add logging of script runner shell cmd at debug level #79
Conversation
Can one of the admins verify this patch? |
e56e115
to
b03a798
Compare
b03a798
to
042460e
Compare
042460e
to
9eaf69d
Compare
9eaf69d
to
736cb4a
Compare
While I like the general notion, it gets way too chatty to my liking with certain bits being logged multiple times from different places.
As a counter proposal, the whole ssh command that gets repeated every time should be the same every time we try to do something with the remote host. How about we log the common part (
|
My goal was to be able to cut'n'paste the command lines for debugging. Splitting it up means I would just end up editing the source on disk again so I don't have to try to manually work out what command was actually executed. |
@@ -300,7 +300,9 @@ def run_async(command) | |||
raise 'Async command already in progress' if @process_manager&.started? | |||
|
|||
@user_method.reset | |||
initialize_command(*get_args(command, true)) | |||
full_cmd = get_args(command, true) | |||
@logger.debug("running command: #{full_cmd.join(' ')}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first element of full_cmd
might contain a hash where there might be effective user password under SSHPASS
key. That should never end up in the logs, no matter the level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely agree. This PR started as a local hack I've made debugging several times over the last few years and wasn't deeply though through.
I realize that ultimately the interface of Process#spawn
has to be satisfied but it is a bit unsettling to have secrets mixed into the same array as the command arguments. It feels like there should be a standard-ish secret or confidential string type that returns something like <SECRET>
or raises an exception on #to_s
but a brief search of rubygems hasn't found such a thing... is there such a thing?
One option would be to filter the args array and remove any hashes as part of the interpolation in the debug statement. How would you feel about splitting the env vars and command line args up into independent data structures that are either merged before being passed to Proxy::Dynflow::ProcessManager#initialize
or changing the interface of that constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there such a thing?
I'm not aware of any standard solution for this, although a custom one should be fairly straightforward to implement.
How would you feel about splitting the env vars and command line args up into independent data structures that are either merged before being passed
I would be fine with this
or changing the interface of that constructor?
I'd like to avoid this. I'd say coordinating changes landing in three different projects and breaking the standard interface ala spawn just to make something, that can be done in a single project with minimal amount of effort, slightly easier is not worth it.
@adamruzicka Yes, the new debug output is great. Thank you. |
I have been manually adding debug logging into my foreman-proxy instances when there is a problem with REX. It seems worth while for the default debug log to contain a trace of shell commands run.