Command that can be used to generate information useful when debugging user errors - #13430
Conversation
|
Hey, can you retitle this and add some labels? Thanks! |
| register_log_source(src, f) | ||
| } | ||
|
|
||
| register_log_source('error', error_f) |
There was a problem hiding this comment.
I think this will lead to good questions for module hacking 👀
acammack-r7
left a comment
There was a problem hiding this comment.
This should save us a lot of time! Some notes about logging and strings.
4819f9b to
b9def68
Compare
| output = Debug.preamble + output | ||
| print_line output |
There was a problem hiding this comment.
❔ Is this the same? 🤔
| output = Debug.preamble + output | |
| print_line output | |
| print_line Debug.all(framework, driver) |
There was a problem hiding this comment.
No not necessarily, if you run debug with no args then you'll get the result of Debug.all. If there are args to the debug command then the user is either looking for help (-h) or is looking to display only some parts of the debug command (Eg debug -e -l for logs & errors).
A user could pass all the flags (debug -d -H -e -l -v ) and get the same result as debug with no args, save potentially a different order of information. This is the only instance where the above lines are the same.
|
|
||
| end | ||
|
|
||
| def self.errors |
There was a problem hiding this comment.
Now that we've got errors appearing as expected in the framework log, what are your thoughts on this section? Is this section now redundant if the log section now has all of the same information? 🤔
There was a problem hiding this comment.
No I don't think so, the log command is relatively dumb and just returns the last X lines of the log file. Errors will scan the log file for the last Y number of errors and extract them in their complete from, stack traces and all. That's useful functionality, and at the very least acts as a tl;dr for logs
| logs_str = concat_str_array_from_last_idx(log_lines, LOG_LINE_TOTAL) | ||
|
|
||
| build_section('Logs', | ||
| 'The following logs were recorded before the issue occurred:', |
There was a problem hiding this comment.
nab: It might be easier to debug this log file if there was additional information on when the shell was opened, to help cross-correlate things better
There was a problem hiding this comment.
As in putting messages on the log file to say "Hey, a new shell was opened here" and some identifying info?
There was a problem hiding this comment.
Sorry, the time at which msfconsole was opened. We probably don't care about stale logs.
There was a problem hiding this comment.
The comment was in a similar vein to https://github.com/rapid7/metasploit-framework/pull/13430/files#r444918893 - were we probably don't care about 10 errors ago 🐛
There was a problem hiding this comment.
This is kind of what I was going for with the optional arguments, as it would let people choose how long the log line total and error total are. However, you're also right that there's no real reason people would care about details spanning multiple console sessions, and manually guess working that with optional log line numbers would be a pain.
There was a problem hiding this comment.
Would say this is more of a seperate PR to improve logging, then debug can build on said improvements
Changes implemented
11d9aba to
d89cbb2
Compare
Release NotesA |

Adds the
debugcommand, that can be used to generate information useful when debugging errors.Context
The purpose of this command is to generate a detailed error report that can be attached to Github issues. The
debugoutput is split into five sections:The variables currently in use in the given environment. This section can be copied and pasted into your
~/.msf4/configfile to recreate the environment that caused the error.The last 50 commands run by a user
The last 10 errors logged to
framework.log. The stack traces for any error are also retrieved and do not count towards the error total.The last 50 lines of
framework.log. This can repeat info retrieved with theerrorcommandThe Framework version, Ruby version, Install Root, DB Connection Session Type (if any), DB Connection Name (if any), and the framework Installation method.
These sections are then wrapped in Markdown, which can be copied and pasted into an Issue for easy readability:
