The PERL scripts contain syntax geared toward a specific UNIX environment. These scripts are like "instructions" that tell the server control program how and where to add, modify, and delete accounts on various remote server environments.
When the server control is installed, a directory called PerlScript is created under the ServerControl folder. This directory contains additional subfolders that contain a different set of PERL scripts, depending on the particular UNIX environment it is geared toward. This is what the PerlScript folder might look like:
PerlScript directory
The "*.pl" scripts contain the main script routines. The other scripts are resource managers (identified by the "*.pm" extension), and "feed" information to the main PERL script. For example, the "ISPPower_Interface.pm" script serves as an interface between the server control program and the main PERL script. It contains initialization routines and other key information for connecting to the remote server. The example below diagrams the generic UNIX PERL scripts and how they interact with each other.
PERL Scripts
The following sections will describe each of the scripts contained in the generic UNIX folder. The specific script configuration settings will vary according to the network setup and the UNIX environment, but the descriptions of the generic scripts should be enough to give a general idea of how the PERL scripts work.
The Server Interface module encapsulates all the complex processing which needs to occur on the servers, such as message passing, encryption, process state control, and signal handling, which frees the other server modules to be simpler and easier to maintain. The Server Interface module is not intended to be edited by the end-user aside from the following settings.
Edit the ISPPower_Interface.pm file
The editable values are explained below.
· SHUTDOWN_RESEND_INTERVAL - Interval between re-sending shutdown notification messages to the Server Control program when the server is shutting down.
· SHUTDOWN_MAX_RESPONSE_TIME - Maximum time to wait for the Server Control program to respond to shutdown notification before continuing to shutdown the server without a response.
· DEBUG - Debugging flag. This variable is initially set to 1 to enable debugging output during the installation process. After the Server Control Add-On has been installed and is functioning properly the variable can be set to 0 to disable debugging output.
This is a library module containing common routines, such as opening and locking the password file and backing up files and directories, which are available for use by the resource manager modules. Since this module handles the bulk of the work required to interface with the system, the module also contains most of the system-specific settings. The configurable settings and their associated descriptions are listed below:
ISPPower_Shared.pm Parameters
This resource manager contains information on how to add user accounts to the password file. It contains various default settings as well as scripts for creating and using objects that will actually create the user accounts. Most of the default settings in this script need not be edited. However, a brief explanation of the settings contained in this script is shown below.
The following four parameters are pre-defined in the PRISM program and should not be changed.
Pre-defined Field Names
The following optionally defined field names may be edited according to preference.
Optionally Defined Field Names
|
|
If you would like to store the information as detailed above, you must make sure that service info codes that correspond to these field names exist. The service info code must match the portion of the field name after the "_". These service info codes should also be mapped to the appropriate service types. See the section Mapping Service Info Codes for more information on this. |
The rest of the settings deal with server operations. Again, these are normally not edited.
|
Parameter |
Default Value |
Description |
|
my($DEFAULT_GID) |
100 |
Default Group ID to use for user accounts |
|
my($DEFAULT_HOME_BASE) |
"/home" |
Default base directory to use for user home directories |
|
my($DEFAULT_HOME_SKELETON) |
"/etc/skel" |
Default skeleton directory to use as a model for new user home directories. The skeleton directory should have the exact structure desired for a new user home directory including the subdirectory layout, files, and mode settings. |
|
my($DEFAULT_SHELL) |
"csh" |
Default shell |
|
my($DEFAULT_MAIL_BASE) |
"/var/spool/mail" |
Default base directory to use for user mail files (user mail files are created as files in the base directory using the user login). |
|
my($DEFULT_MAIL_MODE) |
0600 |
Default mode for user mail files. |
|
my($CLOSED_UID) |
65535 |
User ID to use for closed accounts. Since closed accounts are deleted from the password file, a dummy account and User ID should be created in the password file to own all the files and directories previously owned by deleted accounts. |
|
my($CLOSED_GID) |
100 |
Group ID to use for closed accounts |
|
my($CLOSED_MODE) |
0600 |
Mode to use for files and directories owned by closed accounts. |
|
my($PASSWORD_TIMEOUT) |
60 |
Timeout interval in seconds specifying how long the server should wait to lock the password file before aborting the operation and returning an error status. |
|
my($POP_TIMEOUT) |
300 |
Timeout interval in seconds specifying how long the server should wait to delete a user POP mail file before aborting the operating and returning an error status. |
|
my($POP_FORMAT) |
"/var/spool/mail/.%s.pop" |
Format string to use for creating the pathname to user POP mail files. The user login will be substituted for the "%s" parameter in the format string. |
|
my($RHOSTS_FILE) |
".rhosts" |
Rhosts filename |
|
my($RHOSTS_BACKUP) |
.rhosts.bak" |
Rhosts backup filename. Rhost files are renamed using the backup filename when accounts are suspended to prevent users from accessing their account using a remote login (rlogin). |
This is actually a parameter file for configuring the server. Currently there is only one parameter defined, regardless of what flavor of UNIX used:
LAST_UID - Each time a user is added the uid of the user is saved here to give a starting point for generating the next uid. You can set the next uid used by the server by adjusting this value.
