When the read_recent_text ran off a cliff looking for buffer data,
it left the current textfile handle in a bad state. This caused
the buffer rebuild to fail completely in a scenario where all the
current logs put together don't have enough data to satisfy the
buffer. Fix this by making the handle more obviously broken, and
repairing while seeking out data.
Users have noted and complained that log data was lost, and didn't have old data. This changes
the default behavior to be indefinite retention. Users noting a lot of logs using space have a nice
intuitive indication of old files to delete, and the option remains for those to request a log expiration.
Before the connection would fail and log to trace without anything
particularly informative for the client (they just saw 'unexpected error'.
Provide a more informative behavior for the client.
If exiting from a shell session, the databuffer will contain needed info for the client
to work properly. Preserve databuffer existence. Responsibility for deleting the
object should be in the hands of the caller.
The rollback support and replaydid not follow more than one log back. Do the work to recurse
into older and older files, until big enough buffer or run out of files.
If a user can connect, but gets removed mid session, traces were
being generated. Correct by recognizing the circumstance and returning
the appropriate error to the client.
When initializing security key, a background thread may occur. Sometimes,
the system would go to daemonize while that thread was still running, and
the whole system could exit. Leading to incomplete write to globals as well
as leaving the daemon looking at the data copied over from pre-fork and
seeing the last state of that thread forever frozen. Make sure the background
threads are fully done prior to exiting.
It seems it is possible in some circumstance for the thread id to become stale,
perhaps due to a different threadid executing the code for some reason.
Just in case, ensure the same exact value that was added is later discarded.
This provides a method for client to request session be closed down. This provides more
immediate responsiveness to the client count when closing such a terminal. With this
both closing a single window and doing a 'logout' immediately impacts clientcount.
If something triggers a logout of session, immediately cut into long polling
console sessions that are relevant. This results in web client being able to
immediately detect a logout externally originated.
Provide a means for an http request to erase
it's own session's validity. Always return 200
to allow a client to send bogus credentials and
think they got success to forget the auth data in
the browser.
A javascript client running in browser may want
the standard authorization header suppressed.
This allows a client to block the default browser
authentication prompt.
Like self-signed TLS certificates, SSH host keys
warrant a similar security policy. This implementations
follows the lead of the TLS management and uses the same
policy name and interpretation, just storing the value
in 'pubkeys.ssh' for the node rather than an extensible
set of entry points (for now).
Previously, was using counters to track the relation, also had distinct tracking of users versus
callbacks. Unify the callback and user into a single 'session' attach and then use the size
of the set of sessions and their declared users rather than trying to maintain a counter on the side.
This change simplifies the relationship, changes away the logging and clientcount counter for
a more robust strategy, and paves the way for the dependent ShellHandler to terminate connected
sessions when the shell session dies.
Unlike consoles, where the underlying concept is a real
persistent thing that needs some care to reattach to watch,
a shell session should die when it is lost, as a new one would
have to be created anyway. Modify the disconnect behavior
for a shell session to set closed and notify the receivers.
It should also reap dependent watching objects in a future
change.
This causes some additional features into core. Namely
the ability to use a fixed module rather than a string
defined plugin. This allows shellserver to implement the
'plugin' interface without living in 'plugins'. 'plugins'
implies modularity and potential eventual choice, but
this functionality is core. It would make sense for the
'attributes' plugin to be changed to match this strategy.
When a shell session is initiated, it registers
a recipient at the same time it would be trying
to establish session for not being a 'wait for
recipient'. Aggressively mark the state as connecting
to avoid the recipient erroneously thinking things have
not be set into motion yet. Additionally, have the ssh
plugin avoid a traceback when disconnecting before completing
connection.
Have httpapi recognize the difference and start a shellserver
session when appropriate. Next step will be to wire up enumeration of
current shellserver sessions, debug ssh.py traceback, delete on remote
close, and auto-delete when no client connected after some interval (e.g.
30 minutes).
UUIDs when a simple number will do are harder to use.
Change to a simple increment id. This could cause an issue
with multiple management nodes, but I think the sessions
should be contained to the instance used.
console logging assumptions are not valid for shell sessions.
Correct by modifying the buffer init code to be conditional
and adding a stub 'log' to the ShellHandler class.
