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.
Provide a common 'shellserver' capability cloned off of 'consoleserver'.
This will enable the concept of per-user shells with option for multiple
shells per. Each user will have their own set of shell sessions rather
than shared across users. Can revisit in future if sharing between
users is desired.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
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.
