btbonval / dogiadmin Goto Github PK

Whip together some test certs, replace var tls = require('net'); with var tls = require('tls');, and fill in the options for cert/key/etc.

http://nodejs.org/api/tls.html

This is a continuation of #8.

TLS is implemented for both client and server, but the client refuses to connect to the server yielding some local error.

Here are cases when they don't connect to each other appropriately:

• if the client connects with a certificate that was signed by a different CA, the server disconnects the client. (yay)
• if the client connects trusting a different CA, it will disconnect from the server crying about a bad cert signature. (yay)

Now we just need the client to connect to the server in good conditions:
http://stackoverflow.com/questions/14088787/hostname-ip-doesnt-match-certificates-altname

If a client logins in supplying a client id that is already registered:

• PING the socket registered to that client id
  • if there is a PONG, reject the newcomer
  • if there is no PONG, reject the old socket and accept the newcomer

How long to wait before deciding "no PONG"? On the order of hundreds of milliseconds (nearly 1 second) seems reasonable.

When defining a tac-like file for twistd, protocol factories are assigned to listening ports and then the listening ports are assigned to controlling services.

application = service.Application('dogiadminserver')
internet.TCPServer(3644, daf).setServiceParent(
  service.IServiceCollection(application))

Endpoints seem to be the new and hot thing in Twistd and seem to be encouraged over the various internet.*Server() calls.
"It is, however, almost always preferable to use an endpoint rather than calling a lower-level APIs like connectTCP, listenTCP, etc, directly. By accepting an arbitrary endpoint rather than requiring a specific reactor interface, you leave your application open to lots of interesting transport-layer extensibility for the future."
https://twistedmatrix.com/documents/current/core/howto/endpoints.html#auto6

There are zero examples of using an endpoint to open a port and then calling setServiceParent() so that the endpoint is associated with a Service.

endpoints.serverFromString(reactor, daf.gen_server_string_from_config()).listen(daf)
# what now?? How to associate this with a Service[Collection]??

The current interface to pty.js buffers until newline. When connected to bash at the other end, this prevents tab-completion, history navigation via the arrow keys, ctrl combinations such as ctrl-u, and more.

It's like /bin/sh but with color. sad. This should be fixable.

Server protocol will need to handle an incoming command from the Client if the client is unable to open an SSH tunnel on the requested port.

The server should more or less respond with another call to DogiAdminServerProtocol.request_tunnel(), with a random port generated by default.

The server will need a command from the client which confirms the client has successfully opened a tunnel on some given port. Perhaps the client could make its own port guess attempts since the server isn't providing any real educated guesses about valid ports, and the client can tell the server when a good port has been found.

Presently the server allows one client and one shell.

To make things stupid easy (emphasis on stupid), the server could open a local (unix domain) port for each connected client. The local port will give administrative access (equivalent to the current server UI) via telnet.

That might require buffering if the socket is not connected? Perhaps PTY already does that.

As long as Dogi can find which client is connected at which local port, he can create SSH tunnels to the appropriate port on the server machine.

Create a single function which logs to console.log but also socket.write for the admin socket when it is connected.

Plans were made to facilitate live updates using reload().

It looks like Twisted already has some mechanisms in place which are designed exactly for the desired purpose.
http://twistedsphinx.funsize.net/projects/core/howto/upgrading.html

Instead of executing a reverse SSH tunnel from the client to the server to allow SSH connection to the client from the server machine, it might be possible to run an SSH shell through the already existing management software.

Twisted has SSH support via Conch. Not sure how it works.
http://twistedmatrix.com/documents/current/api/twisted.conch.html

On a related note, it might be good to understand how to start the server software using something like python -m twisted.conch.stdio so that the front-end is already a terminal interface. Unclear how the reactor gets started when running via conch module.

Twisted is simply archaic. One does not learn Twisted to write software for event-driven architectures; one learns Twisted for sake of learning Twisted. The API documentation requires intimate knowledge of all of Twisted (yeah right), the tutorials are sparse (due to lacking useful documentation, if it isn't in a tutorial, it can't really be used), and the community doesn't seem to care about the learning curve (which seems elitist).

Time to find an alternative that is well documented and practically usable without a PhD in the core of the architecture.

Need the right security mechanism to confirm client is as advertised.

TLS Cert should authenticate server to the client, but it wouldn't hurt to add an additional confirmation of server for the client.

The keys almost certainly need to be symmetric so that the Dogi Admin Server can recognize a registered Dogi Admin Client. A little bit of HMAC should do the trick.

It seems that thread-like objects which make repeated calls every so often are managed as Services.

"This version shows how, instead of just letting users set their messages, we can read those from a centrally managed file. We cache results, and every 30 seconds we refresh it. Services are useful for such scheduled tasks."
twistedmatrix.com/documents/current/core/howto/tutorial/protocol.html#auto3

Services also tend to manage the factories which spawn protocols (see above example). This conflation of purpose feels icky. One service should host protocol factories and one service should parse/cache configuration information.

The parser needs to be written as a Service in some sane way which is accessible to the factories hosting the protocols. Maybe there is some other Twisted archetype that fits this specific sort of duty better, but I haven't yet seen it.

Calls to Configurator.config() should be deferred.

This could easily break apart one function into something like three, which is less readable, but it would increase responsiveness. It would also be more in line with the Twisted way of doing things.