LAM Pro allows you to execute scripts whenever an account is created, modified or deleted. This can be useful to automate processes which needed manual work afterwards (e.g. sending your user a welcome mail or register a mailbox). Additionally, you can specify manual scripts that can be executed from within LAM Pro.
To activate this feature please add the "Custom scripts" module to all needed account types on the configuration pages.
In "Module settings" you can specify multiple scripts for each action type (e.g. modify) and account type (e.g. user). The scripts need to be located on the filesystem of your webserver and will be executed in its user environment. E.g. if you webserver runs as user www-data with the group www-data then the custom scripts will be run under this user with his rights. The output of the scripts will be shown in LAM.
You can specify the scripts on the LAM configuration pages.
Syntax:
Please enter one script per line. Each line has the following format: <account type> <action> <script>
E.g.: user preModify /usr/bin/myCustomScript -u $uid$
Account types:
You can setup scripts for all available account types (e.g. user, group, host, ...). Please see the help on the configuration page about your current active account types.
Actions:
Table 4.4. Action types
| Action name | Description |
| preCreate | Executed before creating a new account (cancels operation if a script returns an exit code > 0, not available for file upload) |
| postCreate | Executed after creating a new account (does not run if preCreate or LDAP operations fail) |
| preModify | Executed before an account is modified (cancels operation if a script returns an exit code > 0) |
| postModify | Executed after an account was modified (does not run if preModify or LDAP operations fail) |
| preDelete | Executed before an account is modified (cancels operation if a script returns an exit code > 0) |
| postDelete | Executed after an account was modified (does not run if preDelete or LDAP operations fail) |
| manual | Can be run manually on account page. If you add LAMLABEL="text" before the command then LAM will use the text as label for the button in account edit screen. |
Script:
You can execute any script which is located on the filesystem of your webserver. The path may be absolute or relative to the PATH-variable of the environment of your webserver process. It is also possible to add commandline arguments to your scripts. Additionally, LAM will resolve wildcards to LDAP attributes. If your script includes an wildcard in the format $ATTRIBUTE$ then LAM will replace it with the attribute value of the current LDAP entry. The values of multi-value attributes are separated by commas. E.g. if you create an account with the attribute "uid" and value "steve" then LAM will resolve "$uid$" to "steve".
Please note that manual scripts can only use the current LDAP attribute values of the account. Any modifications done that are not saved will not be available. Manual scripts are also not available for new accounts that are not yet saved to LDAP.
You can switch LAM's logging to debug mode if you are unsure which attributes with which values are available.
The following special wildcards are available for automatic scripts:
$INFO.lamLoginDn$: the DN of the user that is logged in to LAM.
$INFO.lamProfileName$: the current server or self service profile name
$INFO.debug$: list of all possible wildcards and their values (e.g. "$objectClass$:posixAccount,inetOrgPerson; $loginShell$:/bin/bash; $gidNumber$:12345; $uid$:userid...")
$INFO.userPasswordClearText$: cleartext password when Unix/Windows password is changed (e.g. useful for external password synchronisation) for new/modified accounts
$INFO.userPasswordStatusChange$: provides additional information if the Personal/Unix password locking status was changed, possible values: locked, unlocked, unchanged
$INFO.passwordSelfResetAnswerClearText$: cleartext answer to security question
$INFO.389lockingStatusChange$: for 389ds account locking, provides information if account was unlocked. Possible values: unchanged, unlocked
$INFO.389deactivationStatusChange$: for 389ds account locking, provides information if account was deactivated. Possible values: unchanged, activated, deactivated
$INFO.isNewAccount$: specifies if the account already exists or is newly created (yes|no)
$INFO.passwordUpdated$: specifies if the user password was changed (yes|no)
$INFO.passwordChangeType$: password type (manual|random|none) where "none" means no password change
$INFO.passwordChangeModules$: module names of password change operation (e.g. "posixAccount")
$INFO.forcePasswordChange$: a password change was forced (yes|no)
$INFO.sendPasswordViaEmail$: send password via email (yes|no)
$INFO.sendPasswordAlternateAddress$: alternate email address for password email if set (e.g. "test@example.com")
$NEW.<attribute>$: the value of a new attribute (e.g. $NEW.telephoneNumber$) for modified accounts
$DEL.<attribute>$: the value of a deleted attribute (e.g. $DEL.telephoneNumber$) for modified accounts
$MOD.<attribute>$: the new value of a modified attribute (e.g. $MOD.telephoneNumber$) for modified accounts
$ORIG.<attribute>$: the original value of an attribute (e.g. $ORIG.telephoneNumber$) for modified accounts
Output may contain HTML: If your scripts generate HTML output then activate this option.
Hide command in messages: You may want to prevent that your users see the executed commands. In this case activating this option will only show the command output but not the command itself.
You can see a preview of the commands which will be automatically executed on the "Custom scripts" tab. Here you can also run the manual scripts.
