Posts in category unix

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.

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.