Posts in category Licorn

WMI2 branch works on Debian

After a week-end of work, I finally managed to get Licorn® running on Debian Squeeze. Everything is not yet functionnal. Most notably the ServiceExtension class needs a little more love: because it assumes upstart is installed, which is obviously not the case on Debian ;-).

Basic users and groups management works in the WMI. I still need to test a bit more the whole things, but it goes well via the  developer installation.

From another Licorn® machine running Ubuntu, the « Debian » thing is clearly visible (in the Machines tab of the screenshot) ;-)

Related screenshots:

Documentation site is up

We set up  a new site dedicated to Licorn® documentation, growing quickly as we link existing docstrings to it.

Some existing doc from the Trac has already migrated there, and brand new doc will be written, related to profiles management, group memberships, data sharing models between members of a same group, and the like.

Configuration files and directives will be documented there, too.

See you there, keep up bringing peace to the Earth.

Core refactor 001

As you can read in my last big patch (~rev 593), the Licorn® core has been greatly refactorized. There is now a global (but fine grained locked) object, called the LMC (LicornMasterController), which holds all controllers (UsersController, GroupsController and others). It holds 2 other special controllers:

  • the BackendController (real object pretty name: LMC.backends) which has been pulled out from the LicornConfiguration object and holds all backends. The news is that all backends are now equal (there is no level difference between dnsmasq and ldap for example). Backend objects are just much more clean to read and understand. Controllers can use different backends if there's a good reason to. A direct consequence is that LMC.configuration is much simpler than before (and the diet will continue).
  • the LockManager: it is yet just an Enumeration but will become soon a more clever object. It holds all locks for all other controllers, and all locks for controllers unique records. Locks are stored outside of controllers because Pyro can't pickle lock objects (which seems quite fine if you think about it). The LockManager (real object pretty name: LMC.locks) is not exported via Pyro, because all other controllers use it internally and it is not meant to be accessed directly. To lock an object remotely, just call <controller_name>.acquire() and release() methods as you would on a normal lock and the LicornCoreController class will wrap everything for you.

The LMC is accessed directly in the daemon, and remotely via a single LMC.connect() call, in the CLI and the WMI. Pyro related changes and their consequences in the project are nearing end, and the Licorn® core has benefited a big clean-up from it. This is a big piece of work, and a great enhancement: we gained more functionnalities, guaranteed consistency, fine grained locking, with a much simpler codebase. Let the magic (and hard work) continue.

Licorn® 1.2.1 is out

a bunch of bugs later, the new release has come. Full LDAP support, with many bugfixes. It should be stable, LDAP-wise. I added a few more functionnalities, coming from other milestones.

You know where to report bugs. Don't forget to read the Installation How-To?, and the Debian package dependancies, to know what to install. Salute!