scribery / cockpit Goto Github PK

Add another filtering field to recording list: by hostname. Do not show it if there are no recordings from anywhere but localhost, if possible.

Now, since we have implemented all shortcuts in JavaScript, users don't need to send any keystrokes to tlog-play itself. Similarly, the future JavaScript-based player wouldn't need that. Therefore, we need to remove the ability of the terminal to take focus. Otherwise it captures keystrokes and masks them from the browser, which is confusing and annoying.

It might be a good time to switch to xterm.js, which is maintained and updated instead of deprecated term.js.
This might be beneficial for cockpit also.

Implement enabling/disabling recording via user shell change. Change user shell to /usr/bin/tlog-rec-session when enabling, change back to user's shell when disabling. The problem is that we don't know which should the user shell be. Perhaps provide a default, or a choice when disabling.

Lookup "tlog" user ID upon initialization, and use it to filter out all recording log messages instead of looking up by a hard-coded UID.

Switch to use moment.js or Date object to handle all related dates tasks.

Related to #34

Since we need to have some tlog-rec-session options configured in a specific way, namely:

• writer set to journal,
• what to log set to output and window at least,

we need to make it clear to the user when they aren't and either not allow changing them through the UI and preserve them, or allow changing but make it very clear that certain configurations won't allow viewing recordings in Cockpit.

Allow searching recordings for a string appearing in input and/or output. This can be implemented as another filter field. But the search results should also perhaps include timestamps of the matches, clicking which should open recordings at corresponding times.

See also #17.

Support opening listed recordings in new tabs/windows by e.g. right-click menu, ctrl-clicking, middle-button-clicking, and shift-clicking. Consider simply wrapping each cell's contents in an A element.

Let's start with play/pause, fast-forward, slow-play, rewind to start.

Playback user input, perhaps in a little, single-line window underneath the terminal.

The datetimepicker class and its use need to be refactored. In particular:

• The class user shouldn't care about parsing what component provides
• The class user shouldn't have to keep the last correctly-parsed date and should always receive both the last parsed date and the current text input from the component

Show hostname the recording was made on, but only if there were any recordings done anywhere but localhost in journal, if possible.

This will require remake of current handling of URL. Possible to make with GET parameters or additional attributes.

We need to be able to control terminal I/O playback, when running tlog-play in a JavaScript terminal. The easiest and the most economical way to do that is to implement keyboard-driven control in tlog-play and then feed the JavaScript terminal with the control keys. Such as "space" for pause/play, cursor keys for fast-forward/rewind, etc.

Implement proof-of-concept of such a system. First, before tlog-play actually has any control, try to implement a set of on-screen buttons appearing beside the terminal. Let's say a "play/pause", a "rewind to start", a "fast forward" and, a "skip to end" button. Clicking those buttons should produce input characters for the program running in the terminal.

Test by running a shell under the terminal instead of tlog-play and checking if the characters that the buttons should generate appear on the command line.

Before we get to implementing pure JavaScript terminal playback with all the features (and complexities) that it will bring, consider implementing receiving playback position from tlog-play running on the host, within the JavaScript terminal emulator we currently have in Cockpit.

We might be able to do this by modifying the terminal emulator slightly to interpret custom control sequences containing time information coming from tlog-play (Scribery/tlog#107).

See if this can be done with minimal impact to the terminal and quickly. Perhaps have a support for generic hooks for receiving certain escape sequences, in the JavaScript terminal emulator.

From user stories:

• I should be able to choose the sessions that were recorded during a
  specific period of time.
• I should be able to enter the range to narrow the search.
• I should be able to alter the range to widen or to further narrow down the
  search
• The range should have reasonable defaults (for example last 30 days) when
  the selection screen is presented
• The range should allow up to minute granularity with hour-aligned
  defaults
• The controls should be user friendly, so that I do not have to type date
  or time as text into the search criteria, but could select some
  pre-defined ranges
• The range might be expressed as a range of dates as well as a range from
  now till X days back

When resizing of the player according to recording is implemented, consider changing font size to accommodate new number of rows and columns, while keeping the terminal size on the page the same. Allow the user to resize the terminal manually, but again change font size, not number of columns/rows.
This would remove the hassle of terminal size suddenly changing, playback control buttons moving, and scrollbars appearing/disappearing, which would force the viewer to scroll around, possibly missing something in playback and generally getting tired and irritated.

We might still need to allow user to change the number of rows and columns in the playback terminal, in case window resizes weren't recorded or were wrong.

Since journald can also receive logs from other hosts, it is possible that TLOG_REC values can collide in the same journal, since they would be generated on separate hosts.

Use _HOSTNAME in addition to TLOG_REC to uniquely identify recordings. However, if it's not actually guaranteed to be unique (likely), check if there is a more reliable way to identify origin hosts for journal messages.

See https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html and https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html

At the moment, when recording is being played back, Cockpit runs two journalctl processes: one for updating recording information, another for loading the recording itself. Make sure there is only one journalctl running in that case.

When we are choosing anything but today's date, when time picker window opens, it should be reset to 00:00:00. It doesn't make sense offering the default of current time if we're choosing another day.

Right now terminal looks ugly, possible CSS issue. This should be improved step by step.
Here are steps to be done:

• Fix width and height of a terminal.
• Let user to change it's size.
• Resize terminal by tlog-play.

Make sure that when I type text into an input control on the recording page, my keystrokes are not interpreted as playback control shortcuts

It would be nice to have a playback location bar in Cockpit, even with the on-host playback already. We might be able to do this if we manage to get playback position from tlog-play (#5).

Based on user stories description.
Add two date time pickers to the upper part of user sessions list.
Default range will month back from current date.
Format of date time should match back-end format.

We might be able to develop the Cockpit UI as a separate Cockpit package. Doing so might give us more flexibility and development speed.

See @dperpeet comments in Scribery/meta#4.

If communicating current terminal playback position is proven possible with on-host playback (#5), consider adding a window displaying other log messages recorded at the current position (say within 5 seconds), in the same audit session, updated as playback position changes.

Add sorting parameter to URL to save sorting state.

When amount of whitespace between date and time in "since" and "until" fields changes, the recording list is refreshed, even though the actual date and time don't change. This should not happen.

After entering any of the filter values, then viewing a particular session, and returning to the list, filtering remains in effect, but actual filtering values disappear from input controls.

There is bug on window resize - it should not have effect on terminal div now.

There can be a lot of log messages produced/recorded even for a small duration of session recording, and if we allow users to expand the displayed snippet of the logs related to the current terminal playback location, then that will become worse.

Provide a way for the user to limit the displayed messages to those he/she is interested in. Perhaps something like a quick-search on-line filter could work. The criteria can be just a text search of the message, or some specific journal fields.

• Show full name, and not only user name, to ease identification.
• Showing how many items are currently shown and the total number to
  help filtering.

Create filtering by group input ( close to user picker ).

Add hostname column to recording list, but don't display it if recordings belong to localhost only, if possible.

Find out current state of integration.

• Harmonize the date format so it's consistent with the Logs (name of
  month, date).
• Simplify the time format to make it easier to read. For example, don't
  show the year, unless it's not the same as the current year.

Implement sorting recordings by host, username, session start/end time, and duration.

The View component tries to keep recordings in order, but since we added sorting to the RecordingList component, we don't need that and it's better to remove it to keep the code shorter and clearer.

Set reasonable date time period ( one month ? ) for default View of recorded sessions.

Instead of keeping, passing around, and filtering messages with boot ID, audit session ID and PID, use TLOG_REC logged by latest tlog master.

Re-implement playback features done with tlog-play fully in the browser, in JavaScript.