Date: Sat, 13 Apr 2013 13:21:37 +0300 (EEST)
From: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
To: alpine-devel@lists.alpinelinux.org, acf@lists.alpinelinux.org
Subject: [alpine-devel] ACF2 development update
Message-ID: <alpine.LFD.2.03.1304131319210.10105@kunkku.net>
User-Agent: Alpine 2.03 (LFD 1266 2009-07-14)
Precedence: list
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Hello,

Here is a short summary of the state of the ACF2 work. The original
architecture specification for ACF2 is available here:

http://www.datakunkku.fi/acf/

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):

git://git.alpinelinux.org/kunkku/acf2

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:

http://git.alpinelinux.org/cgit/kunkku/acf2/tree/protocol.txt

Apart from dev-shell, no client has yet been implemented. I tried to
implement a single-page JavaScript client based on Backbone.js as
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:

   http://git.alpinelinux.org/cgit/kunkku/acf2/tree/acf/modules/awall.lua

* 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.

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---