Going client/server

[Bohuslav Kabrda]

Thanks for sending this, Tomas. My comments are inline (since we've discussed this together previously, I'm ok with this, I just have some minor nitpicks :)).

----- Original Message -----
> Greetings, friends of all things DevAssistant.
> 
> For eleven minor versions, DevAssistant has been the tool to set up
> your environment on your host system, on bare metal. That works very
> well, but an increasing number of developers can't use it for their
> use case. Why, you ask? Containers. While DevAssistant has very basic
> support for containers in the 'Docker' assistant, it still does all
> the magic on the host. What we need is a full-fledged containerised
> app support, and DevAssistant will have to change quite fundamentally
> to offer it.

... while trying to not discard the current use-cases, where possible. My perception of this is that we should pursue this goal as much as we can. If we need to sacrifice some generality of DA along the way, then so be it - but only if it's absolutely necessary.

> Right now, DevAssistant is pretty much a monolithic application that
> runs on the host machine, requires GTK+ for its GUI and makes some
> assumptions about what the environment looks like. That makes it quite
> hard to make it work reliably under Mac OS X or Windows, heck even
> different Linux distros. To overcome this problem, I suggest
> splitting DevAssistant based on the client/server architecture.
> 
> The basic idea is that the server runs in a privileged container or on
> the host system,

Or in a virtual machine, or possibly even on a remote machine.

> and very thin client connects to it and exchange
> information about assistants and commands through an API (for example
> using JSON). You may think about it as "DevAssistant as a service".
> 
> When developing this architecture, I have heavily borrowed from
> Cockpit, the web-based sysadmin tool developed for Fedora, which uses
> a webserver to accept commands, and then, through a bridge app, issues
> calls to various system services. DevAssistant then should be
> reorganised into these components:
> 
> The client
> ----------
> 
> While DevAssistant uses already a sort of a client-server
> architecture, the clients are still quite thick, and not easily
> replaceable. Our intention is to put only the bare minimum into the
> client - an engine to construct a user interface from the received
> data. That means that the command line interface will construct a help
> message with assistants and commands based on what is available on the
> server side. Similarly, the WebUI will construct a form based on
> fields that the server sends to it, generated from the arguments
> specified in an assistant. The client always runs under the user that
> wishes to run an assistant.
> 
> I am acutely aware of the fact that by using the web interface for
> running commands under the root user, I am effectively delegating the
> security to the browser, but I doubt we currently have the resources
> to have a new full-fledged GUI based on some desktop graphical
> toolkit.

I even think that doing our own GUI would be vulnerable to a hundred and one different CVS that we wouldn't know about. Using web browser is both convenient, easy to implement and doesn't require any special software installed on user's machine.

> The webserver
> -------------
> 
> The webserver is the front-facing part of the entire server, which
> interacts with the client. What it does is spin up a "bridge" instance
> (see below) for the user under whom the "client" is running, and pass
> messages between the two.  The webserver itself doesn't touch the
> system or containers in any way, and will probably run under a unique
> user, for example 'devassistant'. I expect it will take the list of
> available users from /etc/passwd. I still don't know what webserver to
> use, but security is definitely what we should look at first.

IMO flask is secure enough, while also being lightweight and flexible. I don't have a strong opinion here, so feel free to propose a different solution.

<snip>
> This is the general plan of remodelling DevAssistant to better suit
> containerised development. I would like to know your ideas about or
> criticisms of this outline, as it may shape the development for months
> or years to come.

I think that there's one side effect that this will have that you didn't point out - it will be pretty much impossible to install DA by "pip install" in this paradigm. It'd be close to impossible to do manage enabling system services, creating "devassistant" user etc. with "pip install". I'm ok with this, since that's the way I've wanted to move anyway. I just think it's worth pointing out :)

Again, thanks a lot, Tomas!
Slavek

> Cheers, Tomas Radej