1. Account types
LAM provides multiple account types (e.g. users, groups, hosts).
A module can manage one or more account types.
The types are specified with
can_manage().
Example:
Our
ieee802Device
module will be used only for host accounts.
/**
* Returns true if this module can manage accounts of the current type, otherwise false.
*
* @return boolean true if module fits
*/
public function can_manage() {
return $this->get_scope() == 'host';
}
|
2. Base modules
In LDAP every entry needs exactly one
structural
object class. Therefore all modules which provide a
structural object class are marked
as
base module.
This is done with
is_base_module()
or
meta['is_base'].
Example:
The
inetOrgPerson
module manages the structural object class "inetOrgPerson" and
therefore is a
base module.
If your module is not a base module you can skip the meta data for
this, default is
false.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// base module
$return["is_base"] = true;
return $return;
}
|
3. Alias name
The module name is very limited, therefore every module has an
alias name. This
alias name has no limitations and
can be translated. It may contain special characters but make sure that
it does not contain HTML special characters like "<".
The
alias name can be the
same for all managed
account types
or differ for each type.
The
alias name is specified
with
get_alias()
or
meta['alias'].
Example:
Our
ieee802Device
module will get the alias MAC address.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// alias name
$return["alias"] = _("MAC address");
return $return;
}
|
4. Dependencies
Modules can depend on each other. This is useful if you need to access
attributes from other modules or the managed object classes of your
module are not structural.
The dependencies are specified with
get_dependencies()
or
meta['dependencies'].
Example:
Our
ieee802Device
module depends on the account module (because it is the only structural
module at this time).
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// module dependencies
$return['dependencies'] = array('depends' =>
array('account'), 'conflicts' => array());
return $return;
}
|
5. Messages
There are many situations where you will display messages to the user.
The modules should define such messages at a common place to make it
easier to modify them without searching the complete file.
The
baseModule offers the $
messages variable for this. It
should be filled by a function called
load_Messages().
The
baseModule will
automatically check if you have implemented this function and call it
at construction time.
Example:
Now let our
ieee802Device
module define a message.
/**
* This function fills the error message array with
messages
*/
function load_Messages() {
$this->messages['mac'][0] =
array('ERROR', 'MAC address is invalid!'); // third array value
is set dynamically
}
|
6. Managed object classes
You can tell LAM what object classes are managed by your module.
LAM will then check the spelling of the objectClass attributes and
correct it automatically. This is useful if other applications (e.g.
smbldap-tools) also create accounts and the spelling is different.
Example:
The
ieee802Device module
manages one object class.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// managed object classes
$return['objectClasses'] = array('ieee802Device');
return $return;
}
|
7. Known LDAP aliases
LDAP attributes can have several names (e.g. "cn" and "commonName" are
the same). If you manage such attributes then tell LAM about the alias
names.
LAM will then convert all alias names to the given attribute names
automatically.
Example:
The
posixGroup module manages
the "cn" attribute. This attribute is also known under the alias
"commonName".
This way the module will never see attributes called "commonName"
because LAM renames them as soon as the LDAP entry is loaded.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// LDAP aliases
$return['LDAPaliases'] = array('commonName' =>
'cn');
return $return;
}
|