rss
Modules (backends and extensions) renamed, better handling
To avoid conflict with eventual future backends and to stick a little more with reality, the unix backend has been renamed to shadow, and the ldap backend has been renamed to openldap. They are held in files shadow.py and openldap.py in the ShadowBackend and OpenldapBackend classes. Much readable, isn't it?
Configuration, testsuite, documentation website are up-to-date with this change.
Module loading is now much more clean: the backends and extensions do not need to be instanciated in their python file anymore, this is taken care by the manager. This makes code much understandable (I hope), shorter, and more standard. Sphinx autodoc can now be used on backends classes too, whereas it wasn't possible before.
core.backends.classes has dissapeared (the related code is now directly inside core.backends.__init__), and idem for extensions.classes (now in extensions.__init__).
So, The python modules filenames and controller classes names changed, and are shorter: e.g. dnsmasq.py holds the DnsmasqBackend (instead of dnsmasq_backend.py containing dnsmasq_controller), and so on. This rule applies for backends and extensions.
Small other renames have landed too, like ModuleManager having becomed ModulesManager and other minor changes.
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!
Something you should know about in multi-backend context
I filled a bug (#221), just to remember about a particular problem in the multi-backend context. It is curently harmless, I can't see any situation where it could do some damage.
Two small changes worth noticing in add user/group
two points which were pushed in revision 279, because bzr don't know anything about cherry picking (or I don't know how to use it):
- system users/groups are now always created in the Unix backend. this is far from perfect because they have to be replicated for ACLs to work and this will NEED to be done for the cluster, but the cluster doesn't exist yet, so don't bother. This is needed for groups like acl, remotessh and admins, which NEED to be created in /etc/group on the local system before the LDAP backend is activated (they are checked/created before the LDAP setup). This is kind of a workaround because it should work event with these groups in LDAP, but this implies some deep reorganization in the LicornConfiguration class, which will be done later (see #170).
- add a --force argument to add user/group, for the particular case of user/group with same name. This was trigerring a bug on old debian/ubuntu systems, but should be bypassable nowadays, because I expect adduser tools to have been fixed on this particular point.
LDAP-backend v1 commited
The first version of LDAP backend is out, numbered Licorn 1.2. On a freshly installed Lucid with an empty slapd, Licorn® will do everything needed to get a fully usable LDAP system (pam-ldap and nss-ldap wise).
Just run the following command:
sudo aptitude install licorn-ldap
And let the magic begins. What it does, summed up:
- install slapd, lib*-ldap and all licorn.
- wait for slapd to be started with the bare minimum configuration.
- setup all the rest of the slapd configuration (chk config -avb; read the gory details on the LDAP backend page).
- enable the LDAP backend on the whole system (mod config -b ldap), including lib*-ldap.
PAM setup should be done by the debian packages, which is the case nowadays on Lucid.
To be sure the LDAP module is available and enabled, just ask:
sudo get config backends
And the system should tell you:
ldap* unix
Everything else is just transparent: you can use Licorn® CLI tools as usual.
There is still work to be done, but it concerns new features only; the LDAP backend is currently feature complete, regarding users and groups.
LDAP configuration taking more time than the backend
I didn't expect that, but new configuration system (cn=config) in slapd and differences in distribution version (karmik and Lucid) prevented me to complete the auto-configuration for LDAP backend (autoconfiguration can be tricky if you want to make it right).
As of now the 'pure backend' (users and groups management) works perfectly over LDAP, provided that you manually setup the slapd frontend ("o" and different "ou"'s). You can find out every detail on the LDAPBackend wiki page. There is more information than you need, because the wiki page expects that you start from a Karmak setup (totally empty), whereas in Lucid the module and backend parts of slapd are already present.
Samba part is not yet implemented, but will come later. It needs several things to be worked out before.
