Here is a short summary of the state of the ACF2 work. The original
architecture specification for ACF2 is available here:
The core parts of the server, transaction manager, Persistence Manager
(PM), and Model Framework (MF) have been implemented. It is possible
to run the server, the code for which is available here (ca. 2 kLOC as
of this writing):
The server implements the protocol described in the protocol.txt file
in the repository. The protocol is of course still subject to minor
changes. A crude implementation of the protocol is included for
development purposes. It is called dev-shell and is actually a wrapper
for bash and curl.
There has been discussion on this mailing list on whether ACF2 is
suitable for remote management and virtual appliance orchestration. I
think it is really good for that purpose. Please take a look at
protocol.txt and provide comments to make it even better:
Apart from dev-shell, no client has yet been implemented. I tried to
suggested in the architecture document, but it turned out that
Backbone.js was too inflexible for ACF2's versatile data model. We are
looking at alternatives, such as Knockout.js and Ember.js.
In addition to production-quality clients, development focus is needed
in the following areas:
* Currently, the server basically requires root privileges to work
correctly. At minimum, we need to isolate PM to its own process in
order to drop privileges for the other parts. Whether we need to do
finer-granularity privilege dropping on PM side, possibly based on
the identities of the logged-in users, still needs to be decided.
User identity-based privilege setting would provide some protection
against privilege escalation attacks but at the same time introduce
additional complexity, which would be visible for at least module
developers and in the worst case also for end users.
* Currently, the uWSGI-based server handles only one HTTP request at a
time. The server can still handle concurrent sessions and
transactions, so this is not necessarily a problem in small
deployments. However, it can become a problem with custom model
actions that take a long time to complete. There are several options
for adding support for concurrent requests, each having their own
difficulties. The difficulties arise from the fact that uWSGI
processes concurrent requests using separate Lua states, even when
configured into single-thread asynchronous mode. The final selection
on the implementation alternative cannot be done until the privilege
separation architecture has been nailed down.
* PM back-ends need some work. The JSON back-end is in a pretty decent
shape. A file system back-end exists but needs polishing. For
example, it would be nice to map references to symbolic links. The
Augeas back-end supports only reading at the moment.
* Basic access control has been implemented, and it is possible to
grant create/read/update/delete permissions for objects. However,
audit trail is missing and the user authentication code is basically
a mere stub. Surely passwords should not be stored as plain text...
* Modules do not yet exist. There is a module for awall which I have
been using for testing but it is not complete either. Please look
here to get an idea about the interface provided by MF:
* Commit tasks are not yet available, but I expect their
implementation to be quite straightforward. Commit tasks are used
e.g. to restart relevant processes once configuration has been
changed. Also here we need to think privilege separation issues.
* Model actions have not been implemented. This is work in progress,
but there are some challenges related to how the client can discover
complex argument types. The current protocol specification combines
metadata discovery with object read request, which makes it
impossible to check the schema for (yet) non-existent objects. If
there were a separate metadata read request, it could be used to
check action argument types as well.
Please comment if you want to provide some ideas to the aforementioned
development areas or any other improvements. Any help e.g. in module
development would also be welcome once we get the core PM back-ends
into an acceptable state.
Received on Sat Apr 13 2013 - 13:21:37 UTC