CHAPTER 9 Populating SIMS with Users and Groups

Populating the Directory from NIS, NIS+, or /etc Files Entries

190

LDAP Data Interchange Format

210

This chapter describes how to populate users and groups from your current directory database to the SIMS directory.

Users and groups can be manually entered into the SIMS system using the imadmin-add-user command or the SIMS Admin Console (see "To Create a User Entry" on page 28), or by modifying the directory. However, it may be easier to migrate users from an existing directory database to the SIMS directory. If the directory from which you wish to populate users and groups is NIS, NIS+, or /etc files, then we provide a defined procedure and scripts to do this. However, If the directory from which you wish to populate users and groups is in a database other than NIS, NIS+, or /etc files, then you will have to extract the desired data from your current directory and put it into the SIMS LDAP directory. This is a process known as provisioning. See the SIMS Provisioning Guide for complete information on this topic. See the SIMS Reference Manual for the SIMS schema.

The remainder of this chapter describes how to populate users and groups from NIS, NIS+, or /etc files.

This chapter does not describe how to migrate user mailboxes from existing mail systems into SIMS. This information is described in Chapter 9, "Populating SIMS with Users and Groups."

Populating the Directory from NIS, NIS+, or /etc Files Entries

Setting the Environment for Directory Population

191

Saving and Restoring Existing Data in the Directory

191

Using ldif2ldbm and ldbmcat to Initially Populate Local Directories

192

Populating the Directory Via the LDAP Server

193

Appendix C, "Populating the Directory Examples

321

Setting the Environment for Directory Population	191
Saving and Restoring Existing Data in the Directory	191
Using ldif2ldbm and ldbmcat to Initially Populate Local Directories	192
Populating the Directory Via the LDAP Server	193
Appendix C, "Populating the Directory Examples	321

This section describes two ways in which to populate the directory with entries for mail users, user aliases, and distribution lists.

	1.	Writing LDIF data directly into the LDBM database using `ldif2ldbm` and bypassing the `dsservd` server. This is a fast way of doing bulk loading. However, there is no schema checking done with this method. Use this method only if you are certain that your LDIF data is compliant with the schema supported by your `dsservd` server.
	2.	Populating the directory via the `dsservd` server. This is a safer, but more time-consuming way of populating the directory using the LDAP protocol.

Note - By default SIMS assumes that all users receiving mail on this server have entries in the LDAP Directory. Mail will not be routed to users by SIMS until the LDAP Directory is populated with entries. SIMS can be configured to forward unroutable mail to a DNS "smarthost"; see "To Configure IMTA Position Relative to the Internet" on page 91 if you wish mail to be forwarded to the smarthost in the event the intended recipient is not in the LDAP Directory.

Directory entries are created from the passwd(4) file and the mail aliases(4) file. These procedures describe populating the directory for use by SIMS, not for general purpose directory use. "Populating the directory" in this scope means "adding User and Alias entries to the directory for use by SIMS." Other attributes may be added to the directory for other uses, but they must not interfere with the attribute/value pairs used by SIMS.

For a look at some sample directory population sessions, refer to "Populating the Directory with User Data--Sample Session" on page 321, "Populating the Directory with User Aliases Data and Distribution Lists --Sample Session" on page 325, and "Populating the Directory with User Aliases Data and Distribution Lists --Sample Session" on page 325.

Setting the Environment for Directory Population

These procedures use many different commands and several different configuration files. Add the paths to these commands to your own shell paths or $MANPATH.

Executable programs and scripts:

/opt/SUNWmail/bin /opt/SUNWmail/sbin /opt/SUNWconn/bin /opt/SUNWconn/sbin

Directory man pages:

/opt/SUNWmail/man /opt/SUNWconn/man

Directory and other management scripts ("dsserv" to start/stop the directory server, "dswebgw" to start/stop the HTML dirsvc server, etc.):

/etc/init.d

Default location of directory configuration files:

/etc/opt/SUNWconn/ldap/current

Location of bilk load configuration files:

/etc/opt/SUNWmail/dir_svc

Saving and Restoring Existing Data in the Directory

Although the directory can't be used to route mail for SIMS until after it is populated with entries, don't assume that the current directory is completely empty. Do not use ldif2ldbm(1M) or do any other actions which truncate the directory without first saving possible contents using the ldbmcat(1M). Save the contents of the directory for later restoration (using ldif2ldbm) as follows:

su to root

Make sure neither SIMS nor dsservd are running:

/etc/init.d/im.server stop /etc/init.d/dsserv stop

cd /opt/SUNWconn/sbin

Decide on a destination directory which has sufficient space to store the contents of the directory in LDIF. In this example we use /tmp.

Run the ldbmcat command.

In the C shell:

% ./ldbmcat -n /var/opt/SUNWmail/ldap/dbm/id2entry.dbb >& /tmp/dbm.ldif

Note that if the directory was empty this will produce an empty file. In this case, you do not need to run the subsequent steps to restore data.

After saving the existing data to a file (/tmp/dbm.ldif in this example), create the new LDIF for entries you plan to add (ex: new.ldif).

This process is described in the sections that follow.

Concatenate the new LDIF onto the old.

Example: cat new.ldif >> dbm.ldif

Load the database with the new LDIF using ldif2ldbm.

If your database is not empty then you will have to use the -c argument to ldif2ldbm to overwrite the database.

Example: ldif2ldbm -c -i dbm.ldif

Note that faster loading can be attained by using the -j parameter to ldif2ldbm.

Using ldif2ldbm and ldbmcat to Initially Populate Local Directories

ldif2ldbm(1M) is a way of writing LDIF data directly to the ldbm database format used by the directory provided with SIMS. ldif2ldbm(1M) must be done locally. It also bypasses certain checks (schema checking of attributes that are mandatory, for example), and therefore may be faster in certain circumstances for bulk-loading large amounts of data into the directory. For example, restoring up a damaged directory from stored LDIF data, or for initially populating a directory from a new batch of LDIF data. Users of ldif2ldbm are advised to carefully read the man pages and to practice their proposed use of this tool in an environment where any mistakes will not affect the operation of shared resources. Some important reminders about ldif2ldbm are:

ldif2ldbm truncates the existing ldbm databases when it is invoked, to ensure that no existing data can corrupt the bulk-load it is about to carry out. If you wish to use ldif2ldbm on an existing, intact, database, you should use ldbmcat(1M), with `-n' flag to first dump the existing ldbm database to LDIF, to which the new LDIF is then concatenated, before loading the entire new batch of LDIF data.

ldif2ldbm completely bypasses the directory schema enforced by the dsservd directory server. Administrators must be certain that data they are entering meets the schema which dsservd enforces via it's dsserv.conf, dsserv.oc.conf and dsserv.at.conf files.There are two ways LDIF data may be added to the directory; by using the LDAP protocol (via ldapmodify(1), or by direct modification to the ldbm database used by the directory (via ldif2ldbm(1M)). Use of the former method is recommended as it does not require you to be on the same system as the database, and automatic merging of existing entries with new values is done. However the latter method may be used by skilled system administrators who are familiar with the procedure, as it requires saving data already in the directory service to prevent data loss.

If you want to verify that your data matches the SIMS schema, use the
imadmin-add-user utility with your LDIF data to create a few initial users. If you can successfully create users, then the data matches the schema and you can use ldif2ldbm to rapidly populate the directory.

Populating the Directory Via the LDAP Server

Starting and Stopping SIMS Components

191

Gathering Data Used to Populate the Directory

191

Gathering Directory Data on Systems Using /etc Files

192

Gathering Directory Data on Systems Using NIS

193

Formatting Data Used to Populate the Directory

197

passwd File Format Rules for imldifsync(1M)

198

aliases File Format for imldifsync

201

Converting the Data to LDIF Format

207

Converting the Data to LDIF Format Using imldifsync(1M), and Adding Data to the Directory Using ldapmodify(1M).

208

Starting and Stopping SIMS Components	191
Gathering Data Used to Populate the Directory	191
Gathering Directory Data on Systems Using /etc Files	192
Gathering Directory Data on Systems Using NIS	193
Formatting Data Used to Populate the Directory	197
passwd File Format Rules for imldifsync(1M)	198
aliases File Format for imldifsync	201
Converting the Data to LDIF Format	207
Converting the Data to LDIF Format Using imldifsync(1M), and Adding Data to the Directory Using ldapmodify(1M).	208

When you populate the directory, you will perform the following steps:

	1.	Gather the data used to populate the directory by taking existing data from other naming or directory services (NIS, NIS+, or /etc/passwd and /etc/mail/aliases)
	2.	Format the data used to populate the directory to ensure that the data can be read by the imldifsync(1M) program
	3.	Convert the data to LDIF format using the imldifsync(1M)command (or your own custom scripts that follow the rules documented below).

Note - imldifsync(1M) replaces ldapsync(1M) (used in earlier versions of the SIMS) for the purposes of generating LDIF for use by SIMS. imldifsync supports the same interfaces as ldapsync, but in addition supports new features such as the client software Web Access. ldapsync is a deprecated interface and will be eliminated in a future release.

Add/modify LDIF data into the directory database used by the directory service daemon dsserv. Each passwd and alias file entry generates numerous lines of LDIF data based on interpretation rules encoded in imldifsync(1M).

The LDIF attributes and interpretation rules needed by SIMS are listed starting on page 198,. Use these to write your own scripts or translation programs to convert passwd and alias file data into LDIF. We recommend that you use imldifsync(1M)at least as an experimental tool to help you understand how to write scripts that generate LDIF.

Note - After initially populating the directory with NIS/NIS+ user entries, you must also update the directory whenever you update NIS or NIS+ with new email user entries. The procedure we describe for initially populating the directory (in the following sections) is the same procedure for repopulating the directory.

Starting and Stopping SIMS Components

You need to have dsservd running while populating the directory, because imldifsync will communicate with dsserv using LDAP. The IMTA and imaccessd daemon should not be running as they rely on a correctly populated directory to work properly. These programs should be restarted after populating the directory.

To stop imaccessd and all SIMS components use:

/etc/init.d/im.server stop

When using ldapmodify, ldapadd, or ldapdelete to change what's in the directory, use the following command to ensure dsservd is running.

/etc/init.d/dsserv start

Note - The imaccessd process should never be killed using the kill -9 command. Use kill without the -9 argument. If kill -9 is used, run
imcheck -c before restarting imaccessd.

Gathering Data Used to Populate the Directory

You will be adding two types of data to the directory:

user information (from /etc/passwd or its equivalent)

user mail alias and distribution list data from /etc/mail/aliases or its equivalent.

This data may come from /etc files or from NIS or NIS+ databases. However it must be in a concise format before it can be converted to LDIF by imldifsync(1M)

The method for extracting distribution list data depends on whether your system is using NIS, NIS+, or /etc files. The following section details how to use the supplied tools to do this for simple user installations. If you have a complex installation you may prefer to write your own tools (using the supplied client side LDAP tools); in that case it is still recommended that you understand the following process before proceeding on your own.

Gathering Directory Data on Systems Using `/etc` Files

The steps below tell how to obtain user-passwd and mail-alias data from system files. When the SIMS IMTA is installed, mail alias and distribution list information is taken from the directory, rather than /etc/mail/aliases. Unless you set up a way for /etc/mail/aliases to update the directory, it will no longer be used. In this case, you should add a comment in the /etc/mail/aliases file to serve as a warning to other system administrators who attempt to add or update aliases.


$ `su` Password: <Enter your root password>

Note - During this process be extremely careful to not edit /etc/passwd!

Change directory to /tmp and issue the copy command to create a single passwd file with all the entries required by imldifsync(1M):


# `cd /tmp` # `sort /etc/passwd > passwd.tmp` # `sort /etc/shadow > shadow.tmp` # `join -j1 1 -j2 1 -o 1.1 2.2 1.3 1.4 1.5 1.6 1.7 -t: passwd.tmp shadow.tmp > passwd` # rm passwd.tmp shadow.tmp

Note - You may use the passwd and shadow file directly instead of the "join" above by using the "passwd-file" and "shadow-file" options in the imldifsync.conf file discussed below.

Change directory to /tmp and issue the copy command as shown to create a mail aliases file for use by imldifsync


# `cd /tmp` # `cp /etc/mail/aliases aliases`

Gathering Directory Data on Systems Using NIS

To obtain user-passwd and mail-alias data from system files, perform the following steps:


$ `su` Password: <Enter your root password>

Note - During this process be extremely careful to not edit /etc/passwd!

Change directory to /tmp and issue the getent(1M) command to create a single passwd file with all the entries required by imldifsync(1M):


# `cd /tmp` # `getent passwd > passwd`

Change directory to /tmp and issue the ypcat(1) command as shown to create a mail aliases file for use by imldifsync:


# `cd /tmp` # `ypcat -k mail.aliases > /tmp/aliases.tmp` # `sed 's/ /: /' /tmp/aliases.tmp > /tmp/aliases` # rm aliases.tmp

Gathering Directory Data on Systems Using NIS+

To obtain user-passwd and mail-alias data from system files, perform the following steps:


$ `su` Password: <Enter your root password>

Note - During this process be extremely careful to not edit /etc/passwd!

Change directory to /tmp and issue the getent(1M) command as shown to create a single passwd file with all the entries required by imldifsync(1M):


# `cd /tmp` # `getent passwd > passwd`

Change directory to /tmp and issue the niscat(1) command as shown to create a mail aliases file for use by imldifsync:


# `cd /tmp` # `niscat mail_aliases.org_dir > /tmp/aliases.tmp` # `sed 's/ /: /' /tmp/aliases.tmp > /tmp/aliases` # rm /tmp/aliases.tmp

Formatting Data Used to Populate the Directory

This section describes how to format the user, mail-alias, and distribution list data to successfully populate the directory.

User information must be in the format defined in passwd(4), or as you would find in /etc/passwd. An LDIF file will be generated from different fields of each user entry, and user entries will be cross referenced with user alias information (from data you provide of the format found in aliases(4)) to create LDIF attribute definitions used by SIMS. The imldifsync(1M)command which generates LDIF output makes certain rigid assumptions about the format of the gecos field of a user passwd entry:

passwd File Format Rules for imldifsync(1M)

The imldifsync command converts information in the passwd file to LDIF, which is the format required for adding entries to the directory database. If you do not specify your own conversion program or script with the option --G, imldifsync(1M) uses a default conversion program which expects the gecos field to be in the following format:

...:given-name surname, generation-qualifier - comment:...

The gecos field is the fifth field in the sequence of colon-separated fields in the passwd file.

An example gecos-parsing script which can be used with the -G option is in
/opt/SUNWmail/dir_svc/samples/imgecos2cn.sh, and may be specified in the imldifsync.users.conf or imldifsync.groups.conf files (discussed below) via the gecos2cn-prog option.

A gecos field that does not conform exactly to this format may still be parsed successfully by imldifsync, and in this case an LDIF directory entry will be created for it; however, a warning message will be generated for each syntactical error that imldifsync encounters, and the resulting attributes may differ from those expected, requiring administrators to make extra efforts to manually ensure the generated LDIF is useful for SIMS.

The following rules are applied when imldifsync parses the gecos field:

Rule 1 -- General Format

The given-name, surname, and generation-qualifier must start with an alphabetic character, can contain alphabetic characters, dashes (-) and single quotes ('), and must end with either an alphabetic character or a period (.). With the specific exceptions described in "Rule 4 -- Surnames" on page 199, uppercase and lowercase characters have no special significance.

The following examples would be converted to valid LDIF directory entries:

:Alice Mary White:

:Philip O'Connor, Jr.:

:John-Paul Simon - mktg consultant:

The following examples would generate a warning message:

:+Aaron J. Brown:

:Esther Great!:

:Mary Anderson *sales*:

Rule 2-- Comments

Anything that follows a space-dash-space sequence ( - ) is interpreted as a comment; also, anything that is enclosed in double quotes or in brackets, even in a non-matching pair, is interpreted as a comment. There can be multiple comments in a single gecos field.

For example:

:Kevin Ascot - Sales Mgr.: the comment is "Sales Mgr."

:Brian Scott (surgeon): the comment is "surgeon"

:Ellen Chelly [CONTRACTOR]: the comment is "CONTRACTOR"

:Ross "the expert" Brand: the comment is "the expert"

:Janice Evans (Quality Group}: the comment is "Quality Group"

:Robert (Bob) Jones - Mktg: the comments are "Bob" and "Mktg"

Rule 3-- Generation-Qualifiers

If there is a comma anywhere in the gecos field (except in comments), the words that follow it are interpreted as a generation-qualifier. The generation-qualifier is optional, but if present, it must not be blank.

The following examples would be converted to valid LDIF directory entries:

:John Smith,Jr.:

:John Smith, Senior:

The following examples would generate a warning message:

:John Smith,:

:John Smith, - Snr:

Rule 4 -- Surnames

The surname is either the last word in the gecos field, or the last word before either a generation-qualifier or a comment. If there is only one word in the gecos field, it is assumed to be the surname. If there are no words in the gecos field, the username is assumed to be the surname.

For example:

:Kate Black: the surname is "black"

:Ann Mary Wells: the surname is "Wells"

:John Smith, Jr.: the surname is "Smith"

:Erwin David BLINK - Engineer: the surname is "BLINK"

Surnames can also consist of several words. In this case, the capitalization is used to distinguish between words that are part of the given-name and words that are part of the surname.

Words that immediately precede the surname, and that are also either all uppercase or all lowercase are interpreted to be part of the surname. This allows naming prepositions such as "le" or "de" in french, and "von" or "van" in german, to be interpreted correctly.

For example:

:Jean-Pierre le GAD: the surname is "le GAD"

:Joe van der Graf: the surname is "van der Graf"

:Jose MARCOS SOUZA: the surname is "MARCOS SOUZA"

:Franz Josef von Bismark: the surname is "von Bismark"

Note the unexpected effect that the application of this rule may have if the gecos field is all lowercase or all uppercase, or if there is an initial letter preceding the surname.

For example:

:gerhard ellis sumner: the surname is "gerhard ellis sumner"

:ADRIENNE CHIU (sales): the surname is "ADRIENNE CHIU"

:Peter K. Wolff: the surname is "K. Wolff"

Rule 5 -- Given-Name

Once the other components of the gecos field have been identified, the remaining words are interpreted as the given-name.

For example:

:Jean-Pierre le GAD: the surname is "gerhard ellis sumner"

:Joe van der Graf: the given-name is "Joe"

:Jose MARCOS SOUZA: the given-name is "Jose"

:Franz Josef von Bismark: the given-name is "Franz Josef"

:Peter K. Wolff: the given-name is "Peter"

If your user passwd information does not meet this criteria then you have three alternatives:

Convert the passwd data to the above format required by imldifsync(1M), using your own custom written scripts to modify the gecos field. Run imldifsync using that data.

Write your own gecos parsing script as documented in the imldifsync manpage, using the example gcos2cn.sh, in /opt/SUNWmail/ldap/samples, and pass that to imldifsync(1M) via the -G flag

Do not use imldifsync at all, but instead write your own LDIF generator that produces LDIF entries with the attributes that SIMS requires.

aliases File Format for imldifsync

The imldifsync(1M) command makes assumptions about the format of the mail aliases file used as input. The command uses the information in the aliases file to generate attributes for an entry. The expected format for the aliases file is described below.

Note - Refer to the manpage for the aliases(4) file for general usage information.

Rule 1 -- General Format for User Aliases

For each user, the aliases file must contain two lines in the following format:

userid: first.lastname

first.lastname: userid@mailhost

where:

userid is the same as the user ID in the first field of the passwd file

first.lastname is usually a concatenation of the user's given name and surname

mailhost is the machine where the user's mailbox resides.

When the aliases file contains this type of information for a user, imldifsync(1M) creates the following attributes:

rfc822MailAlias with value first.lastname@maildomain

mail with values first.lastname@mailhost.maildomain, userid@mailhost.maildomain, and also with the same value as rfc822MailAlias

mailDeliveryOption with value mailbox

mailHost with value mailhost.maildomain

ispAuthorizedServices with values imap, imaps, pop3, sunw_webaccess, sunw_calendar

inetUserMailVersion with value 1.0

inetSubscriberStatus with value active

Note - The maildomain in the attribute values is the mail domain declared in the configuration file for the imldifsync command. This mail domain must be the same as the one declared in the dsserv.conf configuration file.

For example, the aliases file contains the following lines for user Allyn Robinson:

arobin: allyn.robinson

allyn.robinson:arobin@cloud

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mail: allyn.robinson@cloud.Marketing.stream.com

mail: arobin@cloud.Marketing.stream.com

mail: allyn.robinson@Marketing.stream.com

mailDeliveryOption: mailbox

mailHost: cloud.Marketing.stream.com

ispAuthorizedServices: imap

ispAuthorizedServices: imaps

ispAuthorizedServices: pop3

ispAuthorizedServices: sunw_webaccess

ispAuthorizedServices: sunw_calendar

inetUserMailVersion: 1.0

inetSubscriberStatus: active

Rule 2 -- Handling Differing User IDs

The user ID supplied on the first line can be different from the user ID on the second line.

userid1: first.lastname

first.lastname: userid2@mailhost

In such cases, imldifsync(1M) creates the mailDeliveryOption attribute with the value forward, and also creates a mailForwardingAddress attribute.

For example, the aliases file could contain the following lines for user Allyn Robinson:

arobin: allyn.robinson

allyn.robinson:jconnors@cloud

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mailForwardingAddress: allyn.robinson@cloud.Marketing.stream.com

mailForwardingAddress: jconnors@cloud.Marketing.stream.com

mailDeliveryOption: forward

Combining Rule 1 and Rule 2

You can combine the general format described in Rule 1 with the format described in Rule 2, as follows:

userid1: first.lastname

first.lastname: userid1@mailbox, userid2@mailhost

In such cases, imldifsync(1M)creates the mailDeliveryOption attribute with the values mailbox and forward, and creates the mailForwardingAddress attribute.

For example, the aliases file could contain the following lines for user Allyn Robinson:

arobin: allyn.robinson

allyn.robinson:arobin@cloud, jconnors@cloud

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mail: allyn.robinson@cloud.Marketing.stream.com

mail: arobin@cloud.Marketing.stream.com

mail: allyn.robinson@Marketing.stream.com

mailForwardingAddress: jconnors@cloud.Marketing.stream.com

mailDeliveryOption: mailbox

mailDeliveryOption: forward

mailHost: cloud.Marketing.stream.com

Rule 3-- Handling Nicknames

An aliases file can contain more than two lines per user, in which case, the format to observe is:

userid: first.lastname

nickname1:first.lastname

nickname2:first.lastname

first.lastname: userid@mailhost

In such cases, the imldifsync(1M) command creates the rfc822Mailbox attribute with an extra value for each nickname.

For example, the aliases file could contain the following lines for user Allyn Robinson:

arobin: allyn.robinson

arobinson: allyn.robinson

allyn: allyn.robinson

allyn.robinson: arobin@cloud

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mail: allyn.robinson@Marketing.stream.com

mailDeliveryOption: mailbox

mailHost: cloud.Marketing.stream.com

Rule 4-- Handling File Names in Aliases

A user alias in the aliases file can contain a file name, following this format:

userid: first.lastname

first.lastname: filename

where filename must start with a slash ( / ).

In such cases, imldifsync(1M) creates the mailDeliveryOption attribute with the value "file", and also creates a mailDeliveryFile attribute.

For example, the aliases file could contain the following lines for user Allyn Robinson:

arobin: allyn.robinson

allyn.robinson:/var/allyn/mail

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mailForwardingAddress: allyn.robinson@cloud.Marketing.stream.com

mailDeliveryFile: /var/allyn/mail

mailDeliveryOption: forward

mailDeliveryOption: file

Rule 5-- Handling Program Names in Aliases

A user alias in the aliases file can contain a program name, following this format:

userid: first.lastname

first.lastname: |programName

Note that the pipe ( | ) symbol is required to introduce a program name.

In such cases, imldifsync(1M)creates the mailDeliveryOption attribute with the value "program", and also creates a mailProgramDeliveryInfo attribute.

For example, the aliases file could contain the following lines for user Allyn Robinson:

arobin: allyn.robinson

allyn.robinson:|/bin/cat

The imldifsync command extracts the following attributes and attribute values from this information:

rfc822MailAlias: allyn.robinson@Marketing.stream.com

mailForwardingAddress: allyn.robinson@cloud.Marketing.stream.com

mailProgramDeliveryInfo: /bin/cat

mailDeliveryOption: forward

mailDeliveryOption: program

Rule 6-- General Format for Group Aliases

For each group (distribution list), the aliases file must contain two lines in the following format:

owner-aliasname: owner1 [owner2 ...]

[aliasname-request: processor]

aliasname: user1, user2, user3 ...

where:

aliasname is the name of the alias

owner1, owner2, ... are the names of the owners of the alias. An owner can be a member of the group, but not necessarily.

processor is the name of entity who will be responsible for processing requests sent to the alias

user1, user2, user3, ... are the members of the alias

The owner, processor and member entities defined above can be:

A person with an entry in the directory

A person known by an rfc822 mail address without an entry in the directory

A program, introduced by the pipe ( | ) symbol

A file, introduced by a slash ( /)

Depending on where you obtained your data (/etc files, NIS, NIS+) you may have to further format data.

Converting the Data to LDIF Format

LDIF (LDAP Data Interchange Format) is a canonical data form used to represent entries in LDAP databases. Currently a draft-Internet-RFC, LDIF is designed to be a transportable intermediate data form that is portable between LDAP directories. Data must be converted to LDIF before it can be added to the directory. Administrators may use one of several methods to generate LDIF:

Use the supplied imldifsync(1M) program to synchronize input data with data already added to the directory (if such exists).

Write your own scripts or programs to generate LDIF based on passwd, user alias, and distribution list data.

Note - Although this section will involve two files; passwd data first, alias/distribution-list data second, both user passwd and user alias information will be required in the first pass. Do not continue until you have both data-sets ready to use.

A Few Words About imldifsync(1M)

imldifsync(1M) does several things:

maps password and alias entry information into LDIF output.

correlates password file user entries with alias file user entries.

creates certain LDIF attribute values based on passwd and alias input.

fabricates certain DNs required by dsservd if they are not present in the ldbm.

synchronizes changes in the input password and alias files and converts those differences to LDIF. imldifsync may be used to periodically synchronize the LDAP directory with changes to the password and alias files (for example, if users are added or deleted to the password or alias file).

The default configuration files, imldifsync.users.conf and imldifsync.groups.conf, are installed in /etc/opt/SUNWmail/dir_svc/. Converting data using imldifsync is a two phase process. First, the user/passwd data is converted, then the mail-alias/groups data. The two default configuration files are required, one for each phase.

The SIMS installation GUI will set certain values in the default imldifsync.users.conf and imldifsync.groups.conf based on your input. You should keep track of the settings by keeping an untouched copy of these files.

Note - The imldifsync.users.conf and imldifsync.groups.conf files are readable only by root, because the file contains the "bind-DN" and "ldap-passwd" directives, which the SIMS install GUI will set based on what you enter as your Administrative password. You should be aware that anyone with this bind-DN and password can change any aspect of the Directory contents or configuration, and guard the bind-DN and password appropriately.

Converting the Data to LDIF Format Using imldifsync(1M), and Adding Data to the Directory Using ldapmodify(1M).

Change directories to and make a copy of the imldifsync.users.conf and imldifsync.groups.conf files as configured by the SIMS install process.

In the event the modified versions of the imldifsync.users.conf and imldifsync.groups.conf files are lost or damaged you will have the original file saved.


# `cd /etc/opt/SUNWmail/dir_svc` # `cp imldifsync.conf imldifsync.conf.SIMS3.5` # `vi imldifsync.conf`

Edit the imldifsync.users.conf and imldifsync.groups.conf file.

Uncomment the passwd-file, and aliases-file files, and change their values as shown:


passwd-file = "/tmp/passwd" aliases-file = "/tmp/aliases"

By default the imldifsync.users.conf file contains two lines like this:


add-val = { "mailFolderMap: SUN-MS" } ignore-attr = { "mailFolderMap" }

"SUN-MS" is the recommended mailstore for SIMS. However if you chose to use the "/var/mail" type of message store during your Install, you should change "SUN-MS" to "UNIX V7".

You may choose to add other attributes here as well, but there are two rules that must be followed:

Only attributes from the default SIMS schema may be added in this way. User created attributes cannot be added through this interface.

As shown in the example, only attributes which have values common to all users (for the user data generation pass) or groups (for the group/alias-data generation pass) should be added here.

If you want to set a user mail store quota edit users.conf.

The SIMS default setting is "no limit." To set a space limit, modify the mailQuota attribute as follows:


add-val = { "mailQuota: <quota in bytes>" , "mailFolderMap: SUN-MS" }

where <quota in bytes> would be 10000000 if you wanted to set a mail space quota of 10 megabytes. See "Message Store Quotas" on page 162 for detailed information on setting quotas.

Convert the user data to LDIF format.

Use the imldifsync command to generate formatted user data (LDIF) by issuing the following command:


# `/opt/SUNWmail/sbin/imldifsync -c imldifsync.users.conf > /tmp/ imldifsync.users.ldif`

Populate the directory with the user LDIF formatted data.

This must be done before running imldifsync during the alias-data generation pass because imldifsync compares existing data in the directory to newly generated data to determine what will be generated as the groups data.

Use the ldapmodify command to add the new entries to the directory:


# `/opt/SUNWmail/bin`/`ldapmodify -D` bind-DN `-w` ldap-passwd`-f /tmp/ users.ldif`

Refer to the bulleted section above for bind-DN and ldap-password information.

Note - If you already have some entries in the Directory database you should specify the -c argument to ldapmodify in addition to those above, so that ldapmodify will continue to the new entries. ldapmodify will otherwise exit if it tries to add an entry that is already in the Directory.

Convert the aliases/distribution-list data to LDIF format.

Use the imldifsync command to generate formatted user data (LDIF) by issuing the following command:


# `/opt/SUNWmail/sbin/imldifsync -c imldifsync.groups.conf > /tmp/ groups.ldif`

Populate the directory with the aliases/distribution-list LDIF formatted data.