To configure for a Mailstone test run, you typically perform the following steps:
Specify your general test parameters that will apply to all test runs in your General Configuration file.
By default, this file is named general.wld. See General Configuration
File (general.wld).
Specify testbed machine parameters in the Machine Configuration file.
These machine parameters can be used for multiple test runs. By default,
this file is named all.tbd. See Machine Configuration File (all.tbd).
Edit the contents of your System Data file to specify the system configuration data you want appended to test results.
By default, this file is named general.doc. See System Data File
(general.doc).
Customize parameters for a specific test in one or more primary configuration files.
By default, these files use the naming format testname.pl, where
testname identifies a file containing test parameters for a single test run.
The testname.pl file is used on the command line with the mstone
command to run a specific test. See Primary Configuration File
(testname.pl).
Customize service and command parameters for a specific test in a workload configuration file.
By default, these files use the naming format testname.wld, where
testname matches the name of the corresponding primary configuration
file. See Workload configuration File (testname.wld).
Create or modify any additional configuration files that you specify in the primary or workload configuration files.
These might include additional workload or message configuration files.
See Workload configuration File (testname.wld) and Message Configuration
File.
If you have not already done so, create the test users as described in Establishing the Test User Base.
(Optional.) Create the test messages to be sent as described in Test Messages.
Since Netscape provides test messages in a range of sizes, you only need to
create your own if you want to use sizes or contents different from those
already provided.
Run setup to copy messages and executables to testclient as described in Client Machine Setup.
(Even though there are no additional testclient machines in Windows
environments, this also has to be done because the testmaster machine acts
as a testclient machine.)
(Unix only.) If you are using machines other than testmaster as testclients, run checktime as described in Synchronizing Client Machines to verify that the system clocks are within 2 seconds of each other.
Configuring Test Parameters
You specify Mailstone test parameters in configuration files. Configuration files are stored in the mailstone/conf directory.
Configuration Files
There are different kinds of configuration files:
Note: The primary configuration file (testname.pl) specifies test parameters either in the primary file itself, or by including additional configuration files as described in these instructions. Figure 0.2 diagrams a typical relationship of various Mailstone configuration files as described here. But the setup described here is simply a typical example that uses different files for different kinds of parameters. You can set up your configuration file or files as you wish. For example, you could use different files, or include the different kinds of parameter in the same file.
Figure 0.2 Mailstone test files
Configuration File Command Elements
Table 0.2 describes the various command elements you can use in a configuration file.
Weights in Configuration Files
Commands in workload files are assigned a weight factor that determines the relative frequency of the command's occurrence. For example, if the numeric weights you have assigned to all commands called by the test add up to 25, and a particular command has a weight of 15, then that command has a 60 percent chance of being chosen every time a command is executed, while a command with a weight of 5 has only a 20 percent chance of being chosen. By adjusting the weight factors for the different commands, you can balance them according to your needs.
Some workload files contain a single command and the weight specification applies to that command. Other workload files contain multiple command blocks, each of which has its own weight specification
Weight commands use the syntax:
weight nn
where nn is a number representing the weight factor of that command, or command block. For example:
weight 9
assigns the numeric weight of nine to that command.
Specifying Times in Configuration Files
Times are specified in configuration commands by a number followed by one of these time unit designations:
For example, 4m specifies a time of four minutes.
General Configuration File (general.wld)
The general configuration file specifies general configuration parameters that apply to all Mailstone tests across this testbed. By default, the general configuration file is named general.wld.
The default general.wld file contains the following lines:
<Default>
server servername
smtpMailFrom from-address
addressFormat addressformat
loginFormat loginformat
passwdFormat password
numAddresses NNN
numLogins NNN
</Default>
See Table 0.2 for a description of command elements. You can modify this file as needed.
Primary Configuration File (testname.pl)
The primary configuration file specifies configuration parameters for an individual test run. The primary configuration file also identifies the other configuration files used by the test. By default, primary configuration files use the naming format: testname.pl, where testname identifies a particular set of test parameters.
When you run a test, the primary configuration file is specified on the command line using this syntax:
mstone testname.pl [options]
Note: Parameters specified in a primary file can be over-ridden by specifying alternate parameters as command-line options when mstone is run. See Table 0.4 for a description of the valid command-line options.
Primary files are PERL scripts that have the filename extension of .pl. Examples in these instruction use testname.pl as the primary configuration file.
Five sample primary files are provided for your use:
You can create and use additional primary files as necessary. You can name your primary files whatever you want so long as you always include the .pl file type extension at the end of the name. (Note that if you store the file in some directory other than mailstone/conf, you must specify a full path on the command line to identify the file.)
These are the operative commands in typical primary configuration files:
The sample.wld file provides additional descriptions of commands you can use in a testname file and how they are structured.
Note: When creating or editing a primary file, all operative commands must come before the #=== Do not edit below this line === marker.
See Table 0.2 for a description of command elements. You can modify these files as needed.
System Data File (general.doc)
The system data file specifies additional data to be added to the test report. That is, at the end of each test run the information in the system data file is appended to the HTML-formatted test results report. By default, this file is named general.doc. Typically, the system data file describes the Messaging Server being tested. However, you can use this file to add any information you wish to the test report.
The system data file is a block of HTML-formatted text that can be inserted into an HTML file.
A typical system data file looks like this:
<PRE>
<B> Mailhost.domain.com </B>
Netscape Messaging Server 4.1 (2/18/99)
E6000
26x250MHz UltraSPARC-II
6.5GB RAM
A3500 w/ 60x9GB 7200 RPM
store: 5 x (10x9 RAID-0)
queue: 1 x (10x9 RAID-0)
</PRE>
Machine Configuration File (all.tbd)
The machine configuration file specifies the machines that make up your testbed. By default, this file is named all.tbd.
The Machine File in Unix Environments
A typical machine configuration file for a Unix environment looks like:
# machine numprocs threads
# can include files the same way the workload files do
# <include conf/moreclients.tbd>
testclient1 procs threads
testclient2 procs threads
where:
testclient1 and other testclient machines are the client machines participating in the test. The testmaster machine can also serve as a test client if you wish, in which case the testmaster machine would be listed. Note however that the Messaging Server machine should not be a testclient machine.
procs is the number of processes on that machine. For example, 4
threads is the number of threads running on that machine. For example, 10.
For example, if your testmaster machine is named antares, and you want it to also be a testclient, and you are using the sirius and polaris machines as additional testclients, your entries might look like this:
antares 4 10
sirius 4 10
polaris 1 1
As a general rule, it is best to first create a small-scale test with few machines and processes to make sure that your configurations are properly interacting. Then build up to a full-scale test that includes multiple client machines to reach or exceed the capacity of the server.
The Machine File in NT Environments
In Windows NT environments, Mailstone can only be run on a single machine. Therefore, the all.tbd file should only contain a single entry for that machine. For example:
localhost 1 50
Workload configuration File (testname.wld)
The workload configuration file specifies the services and commands to be tested, their weights, and the test message files to be used. Typically, there is a corresponding workload file for each different primary file By default, workload configuration files use the filename extension testname.wld, where testname matches the name of the corresponding primary configuration file.
Netscape provides sample workload files for different kinds of tests: imap.wld, pop.wld, smtp.wld, popimapsmtp.wld, and popsmtp.wld. You can create additional workload files as necessary.
Within the file, each command element is placed on its own line.
Command elements for a particular service (SMTP, POP3 or IMAP4) are grouped together as a block between <command> and </command> tags. For example, the command elements that apply to POP3 are placed between <POP3> and </POP3> tags. Attributes such as HOSTS can be added to <command> tags.
Command elements that apply to the entire test run (all services) are grouped together as a block between <Default> and </Default> tags. Note that command elements in a <command> block or <Default> block override any multi-test defaults specified in the general configuration file (general.wld). And a value specified for a command in a <command> block overrides a value specified for that command in a <Default> block.
For example, the operative portions of the sample popsmtp.wld file look like this:
<include conf/general.wld>
<SMTP HOSTS=client1>
file en-1k.msg
weight 10
#numAddresses 200
</SMTP>
<POP3 HOSTS=client2>
weight 10
#leaveMailOnServer 1
</POP3>
<IMAP4 HOSTS=client3>
weight 10
idleTime 5
checkMailInterval 10
numLoops 1000
</IMAP4>
See Table 0.2 for a description of command elements. You can modify these files as needed.
While it is possible to specify all of a test's configuration parameters in the workload file, you may find it more convenient to use separate configuration files for different parameters. These additional configuration files can be called by <include> statements in the primary or workload configuration files. The sample configuration files supplied by Netscape are modeled on this practice of separating different kinds of parameters into separate files, and calling those files with <include> statements in the initial workload configuration file.
Message Configuration File
The message configuration file specifies the message configuration files that identify the names of the files containing messages to be used in the test and the weight (usage ratio) of each message file. In the sample files supplied by Netscape, the message configuration files to be used are specified in the workload configuration file with <include> statements.
By default, message configuration files use the filename convention smtpNNk.wld where NN is a number giving the size (in kilobytes) of the message being specified. Netscape provides sample message configuration files named smtp1k.wld, smtp5k.wld, smtp17k.wld, smtp20k.wld, and smtp32k.wld.
You can create additional workload files as necessary. The operative portion of a sample message configuration file is shown below:
<SMTP>
file en-name.msg
numRecips N
weight N
</smtp>
(As an alternative to using message configuration files, you could simply insert these message-related commands in the workload configuration file itself.)
If you want to use multiple messages of different sizes in a test, you list multiple message configuration files, each specifying a message file of a different size. For example, to use 1K, 17K, and 20K messages in a test, you would enter the following in the workload configuration file:
<include conf/smtp1k-a.wld>
<include conf/smtp17k-a.wld>
<include conf/smtp20k-a.wld>
See Table 0.2 for a description of command elements. You can modify these files as needed.
Establishing the Test User Base
In order to test a messaging server, you need to create a set of test users and their mailboxes.
Caution: This set of test users should not include the user IDs of any actual system users.
To properly test your server configurations, you should create as many test users as the server is expected to handle when it is in full operation at maximum capacity.
To establish your user base you do the following:
Setting Up Test User-Accounts
Note: The scripts and instructions described in this section only work with Netscape Messaging Serves and Directory Server. To set up the user base to test some other mail or directory server, you will have to create your user base by hand or use whatever tools those servers provide.
Your test users must be created in your LDAP directory. (Netscape Messaging requires an LDAP directory.)
All test users must have user IDs in the format textNN, or NNtext, where text is a text string that is identical for all user IDs, and NN is a sequence number that is unique for each user ID. For example, if you had 100 users, they might have user IDs of test0 through test99.
If multiple mail servers share a single LDAP directory, all the Mailstone user IDs must be unique across all servers. For this reason, in multiple server environments test users are specified using the format: servername-textNN.
Keep in mind that the naming format you use for your test users has to be noted in your configuration file with the addressFormat configuration parameter, the starting number has to be noted with the firstAddress configuration parameter, and the total number of test users has to be specified with the numAddresses configuration parameter. For example, if you create a thousand test users with IDs like server1-test0, server1-test1, server1-test2, your corresponding configuration parameters would look like this:
addressFormat server1-test%ld@server1.airius.com
loginFormat server1-test%ld
firstAddress 0
numAddresses 1000
numLogins 1000
Mailstone includes two PERL scripts named create_accounts_ldif and create_broadcast_ldif. These scripts are stored in mailstone/ldif. You can use these scripts to facilitate the creation of the user accounts needed to test a Netscape Messaging Server working with a Netscape Directory Server.
Before running the create_accounts_ldif and create_broadcast_ldif scripts you need to modify the following lines:
Table 0.3 Required modifications to LDIF scripts
Script's default value
| Modification needed
|
|---|
$domain "servername";
|
The fully qualified domain name (FQDN) of the mail server being tested, as listed in your LDAP directory. For example:
$domain = "server1.airius.com";
|
$mailhost "mailhost";
|
The fully qualified domain name (FQDN) of the machine that will act as the user's mail host. For example,
$mailhost = "mailserver.airius.com";
|
$basedn "o=netscape, c=US";
|
The base distinguished name (DN) for directory searches on your directory.
|
$userbase "format";
|
The base text string from which to construct user account names for the test. The text string specified here must match the text string specified for the addressFormat parameter in your configuration file (without the %ld). For example, test or server1-test.
|
$userpassword "passwd";
|
The password for all user accounts. This must match the passwdFormat attribute in the configuration file.
NOTE: If you use unique passwords with a replaceable-number format, such as pwd%d, you'll need to bypass or modify this script to accommodate that format.
|
$firstaccount 0;
|
The number of the first account to use. This number must match the number specified for the firstAddress parameter in your configuration file.
|
$num_accounts 2000;
|
The number of test accounts to create. This should be at least as large as the maximum number of users you expect to use in subsequent tests. This number must match the number specified for the numAddresses parameter in your configuration file
|
$storebase "p"
|
On large systems where users are stored in multiple partitions, such as p0, p1, p2, and so on, this identifies partition base name.
|
$maxstores "4";
|
This specifies the number of partitions you are using.
|
$bcastacct "spam";
|
(For the create_broadcast_ldif script only.) Name of the broadcast account.
|
Note: Passwords for your test accounts can be the same for all users. For example, you could use the password netscape for all test users. This would be specified in the general configuration file as passwdFormat netscape. Or you can create unique passwords for all test users by defining a password format that includes a number. For example, netscape0, netscape1, and so on, which would be specified in the general configuration file with passwdFormat netscape%ld.
If you decide to use numbers, you have to bypass or modify this script to accommodate that format.
After editing the scripts as described above, you run the create_accounts_ldif script to create an LDIF file that contains directory entries for all the test user accounts:
# perl/perl ldif/create_accounts_ldif > accounts.ldif
You then add the test LDIF file's entries to your directory. You can use either of the following to update the LDAP Directory from the accounts.ldif file:
Caution: Do not import the test LDIF file. If you import the file, you will create a completely new LDAP database that overwrites your existing directory.
Adding Test Users with Database Manager
You can use the Database Manager feature to add the test user account information in the accounts.ldif file to the LDAP Directory on your instance of Directory Server.
Note: This process will go faster if you first disable access logging on Directory Server.
Directory Server 4.x. To add test users with Directory Server version 4.x, follow these steps:
Make sure the Directory Server is running.
Start up Netscape Console.
Log in.
Open the Server Group containing the instance of Directory Server you want to use.
Double-click the name of the Directory Server.
Click the Configuration tab.
Right-click Database and select the Import menu option.
Enter the name of the file containing your LDIF modifications in the dialog box.
For example, accounts.ldif.
Select Append Data to Database.
Select Add Only.
Select Continue on Error.
Click OK.
Caution: If you are using the Database Manager to update a Netscape Directory Server be sure to use Directory Server's Append Data and Add Only options so as not to overwrite any other entries.
Directory Server 3.x. To add test users with Directory Server version 3.x, follow these steps:
Make sure the Directory Server is running.
Log in to the Directory Server.
You must have read and execute permission to use Database Manager and
read and write permissions for the targeted entries in the LDAP directory.
(You can run this remotely using -h host.)
Go to the Database Manager screen as described in your Directory Server documentation.
Select the Add Entries form.
In the Full Path to LDIF File field, enter the full absolute path name to the accounts.ldif file that contains the test user entries you want to add.
For example: /usr/local/mailstone/ldif/accounts.ldif
Change to Bind to Server field if needed.
Enter the Password.
Click Okay. The entries are added to your Directory Server manager.
Caution: If you are using the Database Manager to update a Netscape Directory Server, be sure to use the Directory Server's Add Entries user interface so as not to overwrite any other entries.
See the Directory Server Administrator's Guide and online help for more information on adding entries to Netscape Directory Servers.
Adding Test Users with ldapmodify
You can use the ldapmodify command line utility to add the test user account information in the accounts.ldif file to the LDAP Directory instance on your Directory Server.
Note: This process will go faster if you first disable access logging on the Directory Server.
The ldapmodify utility is located in server-root/userdb/ldap/tools.
To update the LDAP Directory with ldapmodify, follow these steps:
In Unix environments, make sure your LD_LIBRARY_PATH environment variable is correctly set.
For example:
setenv LD_LIBRARY_PATH /usr/netscape/messaging/lib
Make sure the Directory Server is running.
Log in to the Directory Server system as root.
Go to the directory containing the LDIF files.
For example: ../mailstone/ldif/accounts.ldif
Run ldapmodify to update the LDAP Directory.
For example:
shared/bin/ldapmodify -h mailhost -a \
-D 'cn=directory manager' -w d_m_password \
< accounts.ldif
Caution: If you are using ldapmodify to update a Netscape Directory Server be sure to use the -a option so as not to overwrite any existing entries.
See the Directory Server Administrator's Guide, and online Help for more information on adding entries to Netscape Directory Servers and the ldapmodify utility.
Setting Up Test Mailboxes
One way to create mailboxes for the test users in your LDAP directory is by simply running a Mailstone test. However, since creating mailboxes by running a test is time consuming, Netscape provides the create_broadcast_ldif script that can be used with a Netscape Messaging Server to more efficiently create mailboxes for test users. (This script will not work with other mail servers.)
To create mailboxes for your test users using the script, follow these steps:
Edit the create_broadcast_ldif script as described in Table 0.3
Run the create_broadcast_ldif script as follows:
# ./create_broadcast_ldif >> mailboxes.ldif
Running this script creates the spam broadcast address that initially
constructs the user mailboxes.
Import the mailboxes.ldif file just as you imported the accounts.ldif file.
You can import the file using the Database Manager as described in Adding
Test Users with Database Manager, or with ldapmodify as described in
Adding Test Users with ldapmodify.
Test Messages
The standard test messages used by Mailstone during a test run are contained in message files which are themselves stored in the mailstone/data directory. Five message files of varying sizes are provided for you: en-1k.msg, en-5k.msg, en-17k.msg, en-20k.msg, and en-32k.msg. The number indicates the size of the message in kilobytes. For example, the en-17k.msg file is about 17K long.
(You specify which of message files are to be used in a test with a file en-name.msg statement in the message configuration file as explained in Message Configuration File.)
You can create additional message files as needed. (In Unix environments with testclient machine, if you create new message files you also need to rerun setup to copy the new files to the testclients.)
