Going client/server
by Tomas Radej
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.
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, 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.
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.
The bridge
----------
This is the core part of the new system, which will contain most of
today's DevAssistant package. This part runs under the user who
actually wants to execute the assistants, and is spawned by the
webserver. It loads the available assistants, runs them with
parameters supplied through the webserver, and if necessary, delegates
the execution of superuser tasks to the "service" with elevated
privileges.
The service
-----------
Since the bridge runs under a user that doesn't necessarily have all
the permissions an assistant may require, there will be a service
(DBus?) that accepts commands and executes them as the super user.
When such a command is invoked, the service will ask an authentication
agent if the user is authorised to perform such a command, and based
on the agent's reply will carry it out appropriately. If an additional
authentication is required, the bridge sends a request to the client
for proper authentication.
The agent
---------
The last part of the system is an authentication agent. This agent,
based on its policies, decides if a given user is permitted to carry
out a command passed to the "service", and return a True/False reply.
This will probably be a PolicyKit service.
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.
Cheers, Tomas Radej
8 years, 10 months
- 3
- 9
A feedback/confusion
by Radek Holy
Hi, I'm slowly working on a DAP for DevAssistant. I was asked to provide some feedback. Let me share some of my initial thoughts with you.
For me, the structure of DA's commands is really confusing. E.g. I wanted to fork and clone a GitHub project. I found out that there is a Github DAP. Let's use it. "da modify github --help", "da modify github create --help". Hm, no, this is not for me. OK, there is a Git DAP. No, it provides no "command". OK, let's look at all the DA's commands, maybe I'll find what I'm looking for. "da help". Well, I want to create a new project/fork and also I want to modify an existing project (it's a fork). "da create --help". What about "da create python --help". Hm, probably not. "da modify --help". Hm, nothing for me. What's remaining? "da prepare --help". But it's not going to be an upstream project! I just want to create a pull request. Anyway, "da prepare custom --help". BINGO!
Now, thinking about my DAP... It's going to test a pull request. As part of the tests I want to build its RPM using tito. Maybe I should extend the tito DAP and use it in my DAP. OK but what's the benefit of duplicating the tito's CLI in order to be able to call "da modify tito build --test --rpm" if I can do the same with just "tito build --test --rpm". Let's don't do that. Now, should I create a flexible common DAP for testing any project with the ability to define in a project's .devassistant file how the given project should be tested? But looking at the current DAPs it seems that I should rather create a project specific DAP even at the risk that there are multiple projects that are tested the same way.
But maybe I'm just lazy to think and it's clear to others.
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
8 years, 11 months
- 2
- 2
- ← Newer
- 1
- Older →