search

BashSupport-Pro / bashsupport-pro

Public issue tracking for BashSupport Pro. This is a plugin, which provides advanced support for Bash scripts for JetBrains IDEs.
https://www.bashsupport.com
48 stars 2 forks source link

Remote debugging initiated on the remote host #143

Open jansorg opened 11 months ago

jansorg commented 11 months ago

Requirements

Based on a user's input:

Allow running a script on a remote host to execute a command that connects to a remote debugger console, so the context of a remote execution can be introspected, without the need to try to replicate the entire configuration from a local runner invocation.

The gist being that 99% of remote debugging is done because there's a lot of context/env/parameters/args present in the context in which a script runs on a remote system. Take GitHub actions as an example. There's a ton of remote context one must replicate even to create a remote host that one could ssh into just to debug remotely.

If, instead, one could have an REST endpoint in the local debugger that waits for a connection, and a remote script, (eg within GH actions context) connects to the debugger via this REST API, then one could debug in so many more contexts that are inaccessible from the "debug script X on host Y" run semantics.

Python has

from remote_pdb import RemotePdb RemotePdb('127.0.0.1', 4444).set_trace()

as the remote call-out hook.

Draft for a possible solution

Because there's zero networking support built into POSIX shell and very few support in Bash, most likely a small CLI tool is needed to support this.

Such a tool would be executed on the remote server, which hosts the script to debug. It would create a PTY and pipe it to the developer's machine via https or a similar protocol. bashdb is capable to interact with a PTY without further modifications. It may be possible to reuse existing tools to handle the forwarding, but I haven't searched for it so far.

# On the developer's machine:
# Launch the Bash debugger in the IDE in a new listen mode.
# It would print a connect string, e.g. `https://developerX.example.com:1234`.

# On the remote machine:
# retrieve the cli, e.g. via wget to bashsupport.com
$ ./bashsupport-debug init --url 'https://developerX.example.com:1234'
  > Please use the following command to launch the script to debug:
  > /usr/bin/bash /path/to/bashdb --input /dev/pts/42 -- /path/to/your/debugged/script

# now launch the script to debug
/usr/bin/bash /path/to/bashdb --input /dev/pts/42 -- /path/to/your/debugged/script

Thoughts:

bedge commented 11 months ago

I'm not familiar with the connectivity options available to bash and associated debugger, but ideally, one could leave the remote debugger connect code in delivered systems conditionally, and trigger at some point within an executing script based on the presence of a "debug connect URL" in the env. At least, this is how the python and java remote DB attachments work. Although, I expect they also have a more structured context to work with at connect time and bash may be more difficult to connect to mid-script.

Something like:

if [[ "${REMOTE_DB_URL}" ]] ; then
    <command to connect to remote IDE debugger> <parameters...>
fi

Such that this could be left in a script and invoked as needed by injecting the REMOTE_DB_URL if a remote connection was needed, Rather than needing to glean the full runtime context & env needed to initiate the script remotely.

Regarding the ssh tunneling thoughts: I assumed that ssh tunneling would be needed for most cases as it's rare that one has a port open flapping in the breeze these days. The common use case for the IDE client may be to setup a reverse tunnel on an accessible host so that the DUT could reach the IDE client connection. Or, leverage some existing port forwarder proxy service. This may alleviate complexity on the DUT side, if one assumes that the client IDE end must be internet accessible.

This probably also warrants additional security options, like a token embedded in the REMOTE_DB_URL as a parameter.