The main idea in the design of modules that use the concept of user and/or groups on top of LDAP is to offer a common user interface inside the Users and Groups menu entries. This means that every parameter related to a user or group should appear in those pages, even though each one of those parameters might belong to different eBox modules.
Let's use the samba module implementation as an example. We want
to let the user choose what users are going to have a shared storage
directory. For groups we need to be able to enable/disable a shared
resource for each group, and establish the name of the shared resource.
The goal is to concentrate all these operations that affect user and
group accounts on a common user interface. This interface is the one
provided by the EBox::UsersAndGroups module.
To make this possible, this module has a number of interfaces that allow other modules to include their own options in its GUI and be notified every time a relevant change is made to an user or group configuration data.
The first thing you need to define is what operations on the basic attributes for users or groups are of interest to you. Usually you will want to be notified when a user or group is eliminated or created.
Let's go back to the samba example, when a user
is created in the LDAP server a number of attributes are
established. These attributes are the basic ones defined
by the EBox::UsersAndGroups module,
they are of types inetOrgPerson and
posixAccount. Samba needs to add attributes of
type SambaAccount. This task must be done by the
samba module, so EBox::UsersAndGroups will
notify the samba module that a new user has been created and then the
samba module will add the attributes it needs to the new object.
EBox::LdapUserBase provides
the abstract methods that you need to implement according to
your needs. You only have to implement the methods that your
module needs. Inheriting from this class is the mechanism to let
EBox::UsersAndGroups know that your module is
an Observer of certain operations that happen in
it.
_addUserInvoked when a new user is created, it receives the
username as an argument.
_delUserInvoked when a user is deleted, it gets the
username as an argument.
_addGroupInvoked whenever a new group is created, with the
group name as an argument.
_delGroupInvoked when a group is deleted, it gets the
group name as an argument.
_modifyUserInvoked when a user account is modified, its only argument
is the username.
_modifyGroupSimilar to _modifyUser, but for
groups.
_delUserWarningThis method is invoked every time a user is going to be
deleted, passing to it the username.
Here you need to decide if the removal of that user will mean
changes that the administrator should know about, like the loss
of data. You can return a string explaining the situation and it
will be shown to the user before the user is deleted. Returning
undef means that it's OK to delete the user as
far as your module is concerned.
_delGroupWarningThis method will be invoked whenever a group is
about to be deleted, it receives the group
name as an argument. It works the same way as
_delUserWarning, it will return a string
with a message if deleting this group will cause changes that the
user should know about. Again, return undef if
it's fine to delete the group.
_userAddOns and
_groupAddOnsWhen a user or group is going to be edited, one of
these two methods is called with the purpose of fetching
mason components from your module that
will be integrated in the user interface of the Users
and Groups module. It's only parameter is the
user or group name
respectively. It should return a hash
with two keys: path and
parms. The former contains the path to
the mason template; while the later contains
an array with the arguments to be passed to the template.
_includeLDAPSchemasThis method should be implemented by those modules that need
to include their own LDAP schemas. They should return a reference
to an array that contains the names of the schemas that will be
included int the slapd.conf file.
_includeLDAPAclsThis method should be implemented by those modules
that need to include their own access control lists,
ACLs. They need to return a reference to
an array holding the access control lists to be included in
slapd.conf.
You should create a class that implements those methods
you see necessary. Your class will need to inherit from
EBox::LdapUserBase. You do not have to
implement these method the main class of your eBox module. Your
main class, probably a EBox::GConfModule
subclass, should inherit from EBox::LdapModule
too. This abstract class contains just one method:
_ldapModImplementation, which
should return an instance of the class that inherits from
EBox::LdapUserBase:
sub _ldapModImplementation
{
my $self;
return new EBox::SambaLdapUser();
}