Custom scripts (LAM Pro)
Prev | Chapter 4. Managing entries in your LDAP directory | Next

## Custom scripts (LAM Pro)

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. preModify) 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. Please note that the syntax changed with version 9.2 (see below).

Label:

Here you can enter a descriptive label for the module tab inside LAM.

Syntax:

Please enter one script per line. Each line has the following format: <action> <script>

E.g.: preModify /usr/bin/myCustomScript -u $uid$

Syntax (pre 9.2):

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.sendPasswordViaSms$: send password via SMS (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

Grouping of manual scripts:

If you have a larger number of manual scripts then you can divide them into groups. Add a line "LAM_GROUP: My group description" when you want to start a new group.

Example:

preModify /opt/myapp/preModify.sh -u $uid$
LAM_GROUP: Mail actions
manual LAMLABEL="Clean" /bin/myscripts/cleanMailbox -u $uid$
manual LAMLABEL="Extend" /bin/myscripts/extendMailbox -u $uid$

Interactive parameters for manual scripts

You can define parameters that are specified by the user on the script execution page. E.g., this can be used to specify a target environment (dev/qa/prod).

Interactive parameters allow the user to select the right value instead of having the need to duplicate script entries.

Format: LAM_{TYPE}_{NAME}: {label}={value(s)}

Possible input types:

- Selection

  - Parameter name needs to start with "LAM_SELECTION_", e.g. "LAM_SELECTION_ENV".

  - Values must be separated by semicolons (e.g. "dev;qa;prod")

- Text input

  - Parameter name needs to start with "LAM_TEXT_", e.g. "LAM_TEXT_COMMENT".

  - Value is optional, will be used as default if present.

The parameters can then be used as wildcards in the commands similar to attribute values.

Example:

LAM_SELECTION_ENV: Environment=dev;qa;prod
LAM_SELECTION_TENANT: Tenant=foo;bar
LAM_TEXT_COMMENT: Comment=no comment
LAM_TEXT_AMOUNT: Amount
manual LAMLABEL="Clean" /bin/myscripts/cleanMailbox -u $uid$ -e $LAM_SELECTION_ENV$
manual LAMLABEL="Extend" /bin/myscripts/extendMailbox -u $uid$ -e $LAM_SELECTION_TENANT$
manual /bin/myscripts/syncWithCRM -u $uid$ -c $LAM_TEXT_COMMENT$
manual LAMLABEL="Some app" /bin/myscripts/syncWithSomeApp -u $uid$ -a $LAM_TEXT_AMOUNT$

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.

Prev | Up | Next
Custom fields (LAM Pro) | Home | Sudo roles (LAM Pro)