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.
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.
In the confetty CLI, readline clear history was done as
part of login process. Since readline is not a given
to accomodate scripting behaviors, no longer do the
clear_history(). The concern I had was that
the password might have gotten into history, but that
seems to not be the case.
Expansion of a noderange containing a dynamic group
would erroneously make the dynamic members get promoted
to 'permament' members. Fix this by isolating the
change so that the underlying group config is not changed
just by adding in dynamic nodes.
Jarrod Johnson