APOC: A Point of Control

Time to blog about my project at work.

APOC (stands for A Point of Control) is a set of tools that let's systems administrators to store user profiles on configuration repositories. A user profile is a set of configuration keys with a default value, for example the default background image of the desktop, or the default font for the text processor. The configuration repository can file based, LDAP based, or hybrid (LDAP to retrieve the user and group lists and files to store the profiles), the interesting part of the LDAP support, is that you don't need to modify your existing LDAP tree to use APOC with it, it will find standard user, groups and host domains objects for you. The software supports Sun's Directory Server, OpenLDAP and Active Directory.

The architecture of APOC is simple, we have the profile repository, a web manager to create and apply profiles to the repository and a configuration agent that runs on the client machines. Each application, can talk to the configuration agent to build the configuration tree, to be able to talk with the agent each configuration engine has to make use of its own adapter. Adapters for GConf, OpenOffice.org/StarOffice, Firefox and Java Preference API are already developed and used on production environments.

There are also some command line and GUI tools to create and apply profiles, but they are not as powerful as the web manager.

Everything but the adapters are written in Java,

My work is to help on the opensourcing process, which is not as simple as change the license as you may think. The good news is that the client side it's been approved for CDDL releasing already, although we're studying the possibility of using other license to request approval. This is, the configuration agent, the common layer that talks to the LDAP, the GUI for editing profiles and the C API to develop the adapters.

The web manager, the CLI tools and the adapters are about to start the opensourcing approval process, which will takes a couple of months. Meanwhile, we have some tasks to do.

The most important decision is where should we release the code, we have a couple of options on the table, opensolaris.org, GNOME and freedesktop.org. Each of them has its pros and cons, identity, infrastructure, visibility... hard decision though.

There are other issues that keep me worried for the mid-term. The configuration tools with Java support (see autoconf, waf, CMake), documentation, releasing schedules, but there will be time for that in the future.

Comments

[Wade Mealing]

Gday,

Is there any chance that this kind of library will ever end up on Linux ? CDDL always confuses me a little on what can and can't be shipped legally with a Linux distribution.

We have FDS which should be mostly compatible with Sun Directory Server (IIRC? ), so.. is this a possibility ?

[Alberto Ruiz]

Wade, it works perfectly on Linux, the CDDL only affects if you want to share code with a GPL project, however, we are going for GPL too, we are waiting for the approval.