CONSULTING AGREEMENT
AN AGREEMENT BETWEEN Comat System Solutions Private Limited, India having its
office at 0-0/0, 0xx Xxxx, 00xx Xxxxx, Xxxxxxxxxx, XXXXX, AND CNM Network, 0000
Xxx Xxxxxxx Xxxxxx, 0xx Xxxxx, Xxxx Xxxxxx, XX 00000 to produce a work
tentatively Provisioning System
Whereas, CNM wishes to engage Comat's services as specified herein, and Comat is
ready, willing and able to undertake the rendition of services.
Now, Therefore, in consideration of the mutual agreements herein contained, the
parties agree as follows:
1 OWNERSHIP
1.1 CNM will copyright the Provisioning System in its own name in
conformity with copyright law and with the laws of other countries as
necessary. CNM will have complete and exclusive right of ownership of
the product and all the associated programs, source code, and the data
developed for the purpose.
1.2 Comat agrees to assign and does hereby assign CNM the entire right,
title and interest in and to all software, inventions and designs made
by Comat, alone or with others, which arise out of or pertain to the
services rendered under this agreement, together with any patents
and/or copyrights as may be obtained on the software, inventions and
designs.
1.3 It is understood by CNM that Comat may perform consulting services for
others; providing however, Comat shall not, during the term of this
agreement and a period of six (6) months thereafter, aid any
individual or organization competing with CNM regarding matters
related to this agreement.
2 DESCRIPTION OF WORK
2.1 CNM shall retain Comat and Comat shall do work in the field of
software development. Comat will use its best efforts in the
accomplishment of the software engineering task and goals in building
and refining software for CNM.
2.2 Work will be done in accordance with the Systems Specifications
Document as attached,
3 RESPONSIBILITIES OF COMAT
3.1 Comat will be responsible for developing software with no known bugs.
3.2 The main responsibilities of Comat, carried out in consultation with
CNM include project management, detailed design, programming, testing,
and production of a portable source code. The main tasks are to
design, implement, deliver the final product with complete source code
and documentation to CNM.
4 DURATION
4.1 The duration of the contract is estimated to be a period of four (4)
months beginning May 12, 1998. During this period Comat will assign
resources necessary to complete its responsibilities as described
earlier.
5 CHARGES AND EXPENSES
5.1 For this project, CNM will pay Comat a fee not to exceed $37,900 and
the actual cost will be determined at the completion of the project.
6 PAYMENT TERMS
The total cost of the software development performed by Comat shall be
funded by CNM as follows:
6.1 Comat will invoice CNM on a deliverable basis. The final invoice will
be paid within 10 days of CNM approving final product.
7 DATA SAFEGUARDS
7.1 Comat agrees to make a prompt and full disclosure to CNM, the details
of all inventions, discoveries and improvements made or conceived by
Comat, alone or with others, which relate to the subject of matter of
agreement with CNM.
7.2 Nothing in this agreement shall be construed or implied to create a
relationship of partners, agency, joint venture, or of employee and
employer. As an independent contractor, the commitment on CNM under
this agreement is the performance and fees limited to paragraph 2.
7.3 This agreement cannot be modified in any way except in writing signed
by both parties.
8. TERMINATION
This agreement may be terminated immediately by a written notice if:
8.1 Having given notice of a breach of this Agreement, whereby either
party has failed to provide the services to continue full and active
duties under this Agreement, and whereas the other party fails to
remedy the breach within a reasonable period (and in any event no
longer than 30 days after the notification).
-------------------------------- -------------------------------------
Xxxx Xxxx S.R. Xxxxxx
CNM Network Comat System Solution Private Limited
1900 Los Angeles, 2nd Floor 0-0/0, 0xx Xxxx, 00xx Xxxxx,
Xxxx Xxxxxx, XX 00000 Vyalikaval, Bangalore
INDIA
1 INTRODUCTION 3
--------------------------------------------------------------------------------
2 MODULES 4
--------------------------------------------------------------------------------
2.1 SERVER INTERFACE 4
2.2 REQUEST SERVERS 4
2.3 FAILED TASK QUEUE 4
2.4 SUPPORT MODULES 4
3 TRANSPORT MECHANISM 5
--------------------------------------------------------------------------------
4 MODULE FUNCTIONALITY 6
--------------------------------------------------------------------------------
4.1 SERVER INTERFACE 6
4.1.1 Virtual Web Inteface 6
4.1.2 DNS Interface 6
4.1.3 Incoming Mail Interface 6
4.2 REQUEST SERVERS 6
4.3 FAILED TASK QUEUE 7
4.4 SUPPORT MODULES 7
4.4.1 Machine allocation for new/ altered domain. 7
4.4.2 Domain is available 7
4.4.3 Domain registration confirmation by InterNIC 7
4.4.4 Check user info for Empty fields 7
4.4.5 Check user info for invalid data 7
4.4.6 Saving and retrieving demographic information. 8
4.4.7 Making billing entries. 8
4.4.8 Administration Interface 8
5 INTERFACES 9
--------------------------------------------------------------------------------
5.1 PERL INTERFACE 9
5.1.1 Domain Interface 11
5.1.2 Virtual Web Interface 15
5.1.3 Mail Interface 16
5.1.4 FTP User Interface 17
5.1.5 Mail user Interface 18
5.2 INTERFACE WITH SERVERS 19
5.3 SQL INTERFACE 20
5.3.1 Table Domain 21
6 DATA STRUCTURES 24
--------------------------------------------------------------------------------
7 CLASS STRUCTURES AND PSEUDOCODE 26
--------------------------------------------------------------------------------
7.1 SERVERINTERFACE (BASE CLASS) 26
7.2 USERNAMEINTERFACE (DERIVED CLASS) 28
7.3 DOMAININTERFACE (DERIVED CLASS) 28
7.4 DNS_INTERFACE (DERIVED CLASS) 28
7.5 VIRTUALWEBINTERFACE (DERIVED CLASS) 28
7.6 INCOMINGMAILINTERFACE (DERIVED CLASS) 28
7.7 REQUESTSERVER (BASE CLASS) 29
7.8 USERNAMESERVER (DERIVED CLASS) 30
7.9 DOMAINSERVER (DERIVED CLASS) 30
7.10 DNS_SERVER (DERIVED CLASS) 31
7.11 VIRTUALWEBSERVER (DERIVED CLASS) 31
7.12 INCOMINGMAILSERVER (DERIVED CLASS) 32
7.13 FAILED TASK QUEUE 32
7.14 MACHINE ALLOCATION FOR NEW/ ALTERED DOMAIN. 32
7.15 DOMAIN IS AVAILABLE 32
7.16 DOMAIN REGISTRATION CONFIRMATION BY INTERNIC 33
7.17 CHECK USER INFO FOR EMPTY FIELDS 33
7.18 CHECK USER INFO FOR INVALID DATA 33
7.19 SAVING AND RETRIEVING DEMOGRAPHIC INFORMATION. 33
7.20 MAKING BILLING ENTRIES. 33
7.21 ADMINISTRATION INTERFACE 33
8 TERMINOLOGY 34
--------------------------------------------------------------------------------
8.1 TRANSACTION 34
8.2 TASKS 34
8.3 PROVISIONING SERVER 34
8.4 SERVERS 34
8.5 USER 34
2
PROVISIONING SYSTEM
1 INTRODUCTION
Provisioning system will be a software that will permit users to set up Web,
FTP, mail servers and manage them through web pages. Provisioning system is
being currently viewed as a service to be provided by CNM where users will pay
CNM for services like Web Server, FTP Server etc that would be set up on CNM
infrastructure.
The aspect of this system we are working on starts with a PERL interface calling
up the system with information provided by user. This information is used for
creating, editing or terminating various services. The system will interpret the
requirements and send messages to various servers which actually provide the
service required. As these servers can only be configured from a process on the
same machine, the provisioning system will run a process each on these servers
to pick up the requests and configure the server on basis of the request. The
requests fall in two broad categories first deal with setting up and managing
domains and the second category deals with setting up and managing users on a
domain.
As any interaction between the user and provisioning system can involve more
than one computers, there is a strong requirement to have a error handling
mechanism in the system which will let a task be completed later if it fails on
the first run. This would require some sort of extensive logging of all
transactions and maintaining information on current state of each of these
transactions.
All services provided to the customer will be billed. The provisioning system
will have to inform another software about the services demanded by the customer
so that appropriate billing can be done.
System administration and Maintenance of the software will require facilities to
provide command line inputs to the software and some method of controlling the
monitoring information provided by the system.
The system can be visualised as a set of set of server management functions
which are called either in a predefined sequence (while executing a specific
user request) or individually at random (while executing previously failed
tasks. As all tasks (I believe) originate with user requests, the user request
appears to be the correct starting point at first glance. However, if we take
task execution failures into account and want to build in an ability to complete
failed tasks at a later time, the server management routines become the central
focus of the design.
3
2 MODULES
2.1 SERVER INTERFACE
The server interface routines will broadly belong to these categories:
1. Domain Name
2. User name
3. Virtual Web Server
4. DNS
5. Incoming mail server
Of these routines, the first two do not involve communication with other
machines, and the final execution will happen on the provisioning system machine
itself. The balance requests will be forwarded to the respective servers (for
create requests, only the destination machine type is specified). To maintain
uniformity and expandability, even the first two requests will use the same
mechanism, except for the fact that the sending and the receiving machines will
be the same. The specific transport mechanism used will be restricted to small
piece of code and all other routines will simply submit data for transfer
without bothering about the transport mechanism used.
2.2 REQUEST SERVERS
This module is a separate process, which will run on a different machine and
will receive requests from the provisioning server. The requests will be
interpreted and then passed on to the server being hosted by the machine. The
result will be converted into a data packet and transmitted back to the server.
This module also has transport mechanism dependency, which will also be
restricted to a small piece of code. These servers will need the added
capability of being able to work with different versions of the client software
at the same time.
2.3 FAILED TASK QUEUE
Any non-critical tasks that fail during the first run will be left in a database
to be re-attempted at specified intervals. This is essentially a thread, which
will look for failed tasks and try to complete them. If the thread succeeds to
complete the task, then it will xxxx the record as completed. This thread adds
the feature of graceful and selective degradation of the performance to the
system. As a result, even if some servers are not able to process user requests,
these requests can be left in a queue for later handling.
2.4 SUPPORT MODULES
1. Domain is available
2. Domain registered confirmation from INTERNIC.
3. Check user info for
- Empty fields
- Invalid values
4. Saving and retrieving demographic information.
5. Retrieving billing rates.
6. Making billing entries.
7. Machine allocation for new/altered domain.
4
3 TRANSPORT MECHANISM
The term Transport mechanism has been used to refer to the complete data
interchange/handshake mechanism between two processes. The transport mechanism
to be used will have to be capable of supporting the following features:
- Version control
- Version negotiation
- Multiple result values
The transport mechanism being considered is DATA STRUCTURE WITH VERSION
INFORMATION. Here, all data structures passed around will have major and minor
version numbers. Additionally, the data structures will carry the total data
size as one of the fields. The structure can hold integers, real numbers, fixed
sized strings etc, but for variable size array, the technique used will be to
store the array size and its offset from the beginning of the data structure.
The Data structures used will have a hierarchical growth in structure, with all
related structures having the same common basic fields. This will permit a data
structure pointer to be type cast as a higher level data structured and read or
written to without bothering about its actual format.
5
4 MODULE FUNCTIONALITY
4.1 SERVER INTERFACE
The server interface will be a set of classes inheriting from a common base that
provides the basic functionality and interface format. The base class will have
stubs and generic code for
1. Create, Edit and Delete functions.
2. Logging - Basic functionality of writing logs with time stamp and
incomplete flags raised and upgrading logs to indicate safe completion of
the request. Logs will be written and flags set before any transmissions
are made to protect the system from irrecoverable failure during call
execution.
3. Data Transfer.
4. Error Handling
For almost all inherited classes, the following functionality will have to be
upgraded
1. Create, Edit and Delete Functions.
2. Logging
3. Data Transfer
The classes that will derive form Server Interface and the additional
functionality they will provide are
4.1.1 VIRTUAL WEB INTERFACE
Space required.
4.1.2 DNS INTERFACE
Domain Names, IP Addresses of machines hosting various services.
4.1.3 INCOMING MAIL INTERFACE
Number of users, User accounts, account resources.
4.2 REQUEST SERVERS
Request servers will follow the general framework of Server Interface classes.
The base class will hold the stubs and transport functionality while the
inherited classes will complete the stubs and upgrade functionality of the
transport mechanism.
Additionally, the request servers will support version negotiation and version
checking of the data received. The way data is actually handled will be decided
by the derived classes and the derived classes are free to limit the version
ranges supported.
Care will need to be taken so that exceptions are properly caught and suitable
message is transmitted to the calling interface.
6
4.3 FAILED TASK QUEUE
The failed task queue depends on the logging mechanism of request servers for
input. All calls that fail during initial execution are flagged as incomplete
and will be left for this queue to complete later. This queue will scan the
database for incomplete tasks and verify that their dependency conditions have
been fulfilled (if any). It will then try to execute that task and if
successful, flag the task as completed.
This queue can run on the provisioning system as a thread on the process. The
system will have functionality to send alarm to administrators on exceeding
predefined failure limits.
Functionality may be added here to send message to the user about completion of
the account setup if any of the setup tasks were left for the queue.
4.4 SUPPORT MODULES
4.4.1 MACHINE ALLOCATION FOR NEW/ALTERED DOMAIN.
Multiple machines will host each service. When a new domain is registered, the
services required for that domain will have to be allocated to one of the
machines hosting that service. This module will decide which server will host
each of the services, reserve capacity and make suitable log entries.
If a domain's requirements are altered to the extent that one or more of the
servers' capacity is exceeded, the server for that particular service will have
to be reallocated. This module will also handle these reallocations.
4.4.2 DOMAIN IS AVAILABLE
This module will check the local and the InterNIC database for availability of a
domain. The InterNIC check is a simple whois function call to find out whether
the domain name is in use. The domain could be registered with a third party or
with CNM servers (The DNS servers might be more than the regular primary and
secondary DNS servers). The additional local check is done for two reasons
1. If the domain name is being processed for another user, then it will
definitely not be available for the current user.
2. As the local login names are domain dependent, letting two users apply for
the same domain can cause login clashes that will be very hard to resolve.
The local check will involve checking the list of local domains (a domain here
may still be under process by InterNIC) and list of pending domain requests.
4.4.3 DOMAIN REGISTRATION CONFIRMATION BY InterNIC
Domain registration is an asynchronous and slow process. The confirmation is
expected some hours after the request has been sent to InterNIC. The
confirmation is in the form of an email. This e-mail will have to be parsed to
interpret the domain name actually registered and the time by which it will
become operational. Subsequently, this function will set the necessary flags to
indicate the new status of the domain registration request.
4.4.4 CHECK USER INFO FOR EMPTY FIELDS
Although the front end will do a data validity check to make sure that all
necessary data is present, this level would also run a check on the data that is
vital for the transaction to complete. This level will not bother with data that
is needed only for demographic information. The primary reason for running this
check here is that once this check has been completed, the data availability for
the transaction completion is assured. Another aspect of check at this level is
the check on data validity.
4.4.5 CHECK USER INFO FOR INVALID DATA
This check tries to locate invalid data like wrong or invalid credit card
details, unacceptable numbers supplied for resources like disc space, bandwidth
requirements, number of users etc. A lot of decisions taken at this level will
depend on the system policy.
7
4.4.6 SAVING AND RETRIEVING DEMOGRAPHIC INFORMATION.
The demographic information collected will be written to a database and possibly
associated to the domain. Demographic information, for display, processing and
updates, will be retrieved by this module.
4.4.7 MAKING BILLING ENTRIES.
Non financial billing information will be handled by this module. All purchases/
purchase alterations demanded by the customer will result in a record being
generated by this module. The billing module will use these entries to generate
the financial impact information.
4.4.8 ADMINISTRATION INTERFACE
8
5 INTERFACES
The provisioning system that we will be working on will have three interfaces.
The program will primarily interact with the outside world across these
interfaces. These are:
1. Perl program interface.
2. Interface with servers.
3. Interface with SQL server and tables.
These interfaces constitute the most rigid aspect of the design. Any alteration
of these interfaces requires proper coordination with the team in Simi Valley.
Each of these interfaces has a different communication mechanism and they are
explained below.
5.1 PERL INTERFACE
The Perl interface is a programming interface. Here, the Perl program (to be
developed and maintained at Simi Valley) connects to the provisioning system and
issues commands in the form of Data Blocks. These commands are very similar to
the commands issued by the provisioning system to the server side modules.
Consequently, large parts of data structure will be reused between
Perl/Provisioning system interface and Provisioning system/Servers interfaces.
The Perl interfaces will call up provisioning system on IP port 48000. The data
structures that will be passed are
struct T_PERL_INTF{
int nVersion;
long lBufferSize;
int nCommand;
int eServerType;
char szDomainName[32];
char szAdminUserName[32];
char szAdminPassword[16];
char szUserName[32];
char szUserPassword[16];
int nReturnValue;
char szErrorMsg[128];
};
This is the primary building block for all communication structures. This
structure contains Version information, full command description, Domain name,
Admin user name and password. All subsequent structures are more specific and
are described along with interface functionality description. A few fields whose
behavior remains constant are explained here and will normally not be described
in other sections. They will have further description in other sections only if
their immediate behavior differs from the description provided here or values to
be used are specified.
nVERSION: Holds the version number of the data block. This version number
permits clients with different version numbers to communicate with the same
server. This field is filled on input.
lBUFFERSIZE: Holds the size of the complete buffer. This field will become
critical when the data passed will contain variable length fields. This
field is filled on input and output.
nCOMMAND: Holds the actual command to be executed. This field is filled on
input. The permissible values are:
- CMD_CREATE
- CMD_QUERY
- CMD_ALTER
- CMD_DELETE
- CMD_CHECKAVAILABLE
nSERVERTYPE: Holds the type of server that the command is meant for. This field
is filled on input. The permissible values are:
- SERVER_DOMAIN
- SERVER_VIRTUALWEB
- SERVER_MAIL
- SERVER_USER_FTP
9
- SERVER_USER_MAIL
szDOMAINNAME: Holds the domain name. For all commands except domain creation,
this holds the domain name being referred to. For domain creation, this
holds the domain to be created. This field is filled on input.
szADMINUSERNAME: Holds the administrator user name. This field is filled on
input.
szADMINPASSWORD: Holds the administrator user password. This field is filled on
input.
szUSERNAME: Holds the user name when individual user accounts are being
manipulated. For server level commands, this value is not used. This value
is filled on input.
szUSERPASSWORD: Holds the user password for the user account. For server level
commands, this value is not used. This value is filled on input.
nrETURNVALUE: Holds the return value. This field is filled on output. The
following values are common return values
- SUCCESS: Call successful.
- UNKNOWN_ERROR: Error text is returned in szErrorMsg.
szERRORMSG: This field holds error message if the Return Value does not
sufficiently describe the error condition. If this field is not used, it
will be set to a zero length string.
10
5.1.1 DOMAIN INTERFACE
When the user creates a domain or alters/queries/deletes an existing domain,
these interfaces are used. The data structure T_DOMAIN applies to Create, Query
and Edit interfaces for a domain. The structure needs to be further extended for
Create and Edit interfaces, but is suitable, without changes, for Domain Query
interface.
struct T_DOMAIN {
struct T_PERL_INTF PerlIntf;
// Name of the preson registering the domain.
char szLastName[64];
char szFirstName[64];
char cMiddleInit;
// Residential address
char szResAddress[64];
char szResAddressTwo[64];
char szResCity[32];
char szResState[2];
char szResZip[12];
char szResPhone[32];
// Business Address
char szBusName[64];
char szBusAddress[64];
char szBusAddressTwo[64];
char szBusCity[32];
char szBusState[2];
char szBusZip[12];
char szBusPhone[32];
char szEmail[64];
// Other details
int nSex;
int nAge;
int nMarStatus; // Marital Status
int nNumChild; // Number of Children
int nAnIncome; // Annual Income
int nInetFreq; // Frequency of accessing the internet.
int nInetUse; // Internet utility.
char szInetUse[64]; // Other Internet utility
int nWhereHear; // Source of Information about CNM
char szWhereHear[64]; // Other sources of information.
};
All fields are filled on input for create and alter operations. The fields are
filled for output in a Query operation.
The values stored these variables have importance only for the Perl program and
the Web pages. The complete provisioning module and other modules will merely
treat this information as basic data types and treat them as such. No
validations/checks will be carried out on demographic data at this side of the
Perl/Provisioning interface.
11
5.1.1.1 DOMAIN AVAILABLE
This structure will be used to query the availability of a particular domain
name.
struct T_DOMAIN_AVAILABLE{
struct T_PERL_INTF PerlIntf;
BYTE yDNSAddress[4];
};
The usage of the fields is explained below.
nCOMMAND: CMD_CHECKAVAILABLE.
eSERVERTYPE: SERVER_DOMAIN.
szADMINUSERNAME: Not used.
szADMINPASSWORD: Not used.
nRETURNVALUE: The return status of the domain name query. This field is filled
on return. The permitted return values are:
- SUCCESS: The domain name is not registered and an attempt can be made to
register the same.
- DOMAIN_WITH_THIRD_PARTY: The domain has been registered with InterNIC. The
DNS server pointed to by InterNIC is not owned by CNM. The actual IP
Address of the DNS server returned by InterNIC is returned in the
yDNSAddress field.
- DOMAIN_WITH_OUR_DNS: The domain has been registered with InterNIC. The DNS
server registered with InterNIC belongs to CNM. The actual IP Address of
the DNS server returned by InterNIC is returned in the yDNSAddress field.
- DOMAIN_BEING_PROCESSED: The domain has not been registered with InterNIC,
but our local queue is processing this domain for some other user.
yDNSADDRESS: The IP Address of the DNS server. Check the description of
nReturnValue for validity of this value.
12
5.1.1.2 CREATE DOMAIN
This structure will be used to initiate domain creation. It is necessary that
the user be made to check domain name availability before coming to this stage.
struct T_DOMAIN_CREATE {
struct T_DOMAIN Domain;
char szDomainChoiceTwo[32];
char szDomainChoiceThree[32];
int nCreateMode;
int nBillingMethod;
int nCardType;
char szCardHolder[64];
char szCardNumber[16];
time_t tmExpDate;
};
The usage of the fields is explained below.
nCOMMAND: CMD_CREATE.
esERVERTYPE: SERVER_DOMAIN.
szDOMAINNAME: Hold the first preference for domain name. This field is filled on
input.
szADMINUSERNAME: Admin user to be created.
szADMINPASSWORD: Admin user password.
szDOMAINCHOICETWO: Holds the second preference for domain name. This field is
filled on input.
szDOMAINCHOICETHREE: Holds the third preference for domain name. This field is
filled on input.
ncREATEMODE: Hold the domain name creation mode. This field is filled on input.
This field can have the following values:
- DOMAIN_CREATE_REGISTERNEW: Register the domain name specified. If name
cannot be registered, the call fails.
- DOMAIN_CREATE_TRANSFEROLD: Do not register the domain name. The domain is
owned by the user. CNM has to initiate process to shift the domain name
from the current DNS to CNM DNS server.
- DOMAIN_CREATE_NOACTION: Do not register the domain name. The user will get
the DNS for the domain transferred to CNM DNS server.
nBILLINGMETHOD: Holds the billing method to be used. This field is filled on
input. The permissible values are:
- BILLING_CREDITCARD
- BILLING_RAISEINVOICE
nCARDTYPE: Holds the credit card type. This field is filled on input. This value
is valid only if nBillingMethod is BILLING_CREDITCARD. The permissible values
are:
- CREDITCARD_VISA
- CREDITCARD_MASTERCARD
- CREDITCARD_AMEX
- CREDITCARD_DISCOVER
szCARDHOLDER: Holds the credit card owner name. This field is filled on input.
This value is valid only if nBillingMethod is BILLING_CREDITCARD.
szCARDNUMBER: Holds the credit card number. This field is filled on input. This
value is valid only if nBillingMethod is BILLING_CREDITCARD.
tmEXPDATE: Holds the credit card expiry date. This field is filled on input.
This value is valid only if nBillingMethod is BILLING_CREDITCARD.
13
5.1.1.3 QUERY DOMAIN
This call will be used to query a domain for information. The structure used for
this call is T_DOMAIN structure. Only necessary T_PERL_INTF members of the data
structure need to be filled for making this call.
All demography related members will be filled on return. The usage of the fields
is explained below.
nCOMMAND: CMD_QUERY.
eSERVERTYPE: SERVER_DOMAIN.
5.1.1.4 ALTER DOMAIN
This data structure will be used to make changes to the domain information. All
fields, including the domain name itself, can be changed by the user. All
demographic fields will be overwritten with the new values, so care must be
taken to fill fields with all values, even the ones that have not changed.
struct T_DOMAIN_EDIT{
struct T_DOMAIN Domain;
char szNewDomainName[32];
int bRegisterDomain;
char szNewUserName[32];
int bPasswordChanged;
char szNewPassword[16];
};
The usage of the fields is as follows.
nCOMMAND: CMD_ALTER.
eSERVERTYPE: SERVER_DOMAIN.
szDOMAINNAME: Old domain name.
szUSERNAME: Old user name.
szPASSWORD: Old password.
szNEWDOMAINNAME: New domain name. If old and new domain names are the same, no
domain name changes are made. This field is filled on input.
bREGISTERDOMAIN: Defines whether domain should be registered or not. This
permits users to move the account to a domain registered through some other
means. No DNS server checks will be made while changing the domain name. This
field is filled on input.
szNEWUSERNAME: New Admin user name. If old and new admin user names are the
same, no user account changes are made. This field is filled on input.
szNEWPASSWORD: Holds the new password for the admin user account. This field is
filled on input.
5.1.1.5 DELETE DOMAIN
This call will be used to delete a domain from CNM servers. The T_PERL_INTF
structure will be used for this call. This command will recursively delete all
underlying Virtual Web, Mail servers and all registered users. The usage of the
fields is as follows.
nCOMMAND: CMD_DELETE.
eSERVERTYPE: SERVER_DOMAIN.
14
5.1.2 VIRTUAL WEB INTERFACE
The management of Virtual Web and FTP servers will require the use of structure
T_VIRTUALWEB. This structure will be used for the commands Create, Query and
Alter.
struct T_VIRTUALWEB{
struct T_PERL_INTF PrelIntf;
long lDiskQuota;
long lBandWidth;
BOOL bCGI;
BOOL bFrontPage;
BOOL bAnonymousFTP;
BOOL bSecureKey;
BOOL bPersonalSecureKey;
BOOL bLogs;
BOOL bBackups;
BOOL bStatistics;
};
The usage of the fields is as follows.
eSERVERTYPE: SERVER_VIRTUALWEB.
lDISKQUOTA: Holds the hard disk space demanded by the user. The unit for the
space is Mbytes.
lBANDWIDTH: Holds the bandwidth required for the domain. The
unit for this field is KBits/Sec.
bCGI: Enable/Disable CGI.
bFRONTPAGE: Enable/Disable Frontpage.
bANANYMOUSFTP: Enable/Disable Anonymous FTP.
bSECUREKEY: Enable/Disable Secure Key.
bPERSONALSECUREKEY: Enable/Disable Personal Secure Key.
bLOGS: Enable/Disable logs.
bBACKUPS: Enable/Disable backups.
bSTATISTICS: Enable/Disable site statistics.
5.1.2.1 CREATE VIRTUAL WEB SERVER
This call will be used to create a Virtual Web server. The T_VIRTUALWEB
structure will be used for this call. The T_VIRTUALWEB specific fields are
filled on input. The usage of the fields is as follows.
nCOMMAND: CMD_CREATE.
5.1.2.2 QUERY VIRTUAL WEB SERVER
This call will be used to find out information about Virtual Web server. The
T_VIRTUALWEB structure will be used for this call. The T_VIRTUALWEB specific
fields are filled on output. The usage of the fields is as follows.
nCOMMAND: CMD_QUERY.
5.1.2.3 ALTER VIRTUAL WEB SERVER
This call will be used to alter a Virtual Web server. The T_VIRTUALWEB structure
will be used for this call. The T_VIRTUALWEB specific fields are filled on
input. The usage of the fields is as follows.
nCOMMAND: CMD_ALTER.
5.1.2.4 DELETE VIRTUAL WEB SERVER
This call will be used to delete a Virtual Web server. The T_PERL_INTF structure
will be used for this call. All FTP users for the domain will be deleted by this
call and need not be deleted separately. The usage of the fields is as follows.
nCOMMAND: CMD_DELETE.
15
5.1.3 MAIL INTERFACE
The management of Incoming mail and POP servers will require the use of
structure T_MAIL. This structure will be used for the commands Create, Query and
Alter.
struct T_MAIL{
struct T_PERL_INTF PerlIntf;
int nNumMailboxes;
};
The usage of the fields is as follows.
eSERVERTYPE: SERVER_MAIL.
nNUMMAILBOXES: Holds the number of mail boxes requested by the user.
5.1.3.1 CREATE MAIL SERVER
This call will be used to create a Mail server. The T_MAIL structure will be
used for this call. The T_MAIL specific fields are filled on input. The usage of
the fields is as follows.
nCOMMAND: CMD_CREATE.
5.1.3.2 QUERY MAIL SERVER
This call will be used to find out information about Mail server. The T_MAIL
structure will be used for this call. The T_MAIL specific fields are filled on
output. The usage of the fields is as follows.
nCOMMAND: CMD_QUERY.
5.1.3.3 ALTER MAIL SERVER
This call will be used to alter a Mail server. The T_MAIL structure will be used
for this call. The T_MAIL specific fields are filled on input. The usage of the
fields is as follows.
nCOMMAND: CMD_ALTER.
5.1.3.4 DELETE MAIL SERVER
This call will be used to delete a Mail server. The T_PERL_INTF structure will
be used for this call. All Mail users for the domain will be deleted by this
call and need not be deleted separately. The usage of the fields is as follows.
nCOMMAND: CMD_DELETE.
16
5.1.4 FTP USER INTERFACE
The management of FTP users will require the use of structure T_FTP_USER.
Although the admin user can be setup and altered by altering the domain
information, it is recommended that this channel be used to alter information
about admin user as well. This structure will be used for the commands Create,
Query and Alter.
struct T_FTP_USER{
struct T_PERL_INTF PerlIntf;
int nAccessLevel;
};
The usage of the fields is as follows.
eSERVERTYPE: SERVER_USER_FTP.
szUSERNAME: Holds the account user name.
nACCESSLEVEL: Holds the access level of the user.
5.1.4.1 CREATE FTP USER
This call will be used to create a FTP user account. The T_FTP_USER structure
will be used for this call. The T_FTP_USER specific fields are filled on input.
The usage of the fields is as follows.
nCOMMAND: CMD_CREATE.
szUSERPASSWORD: Holds the account user password. This value is filled on input.
5.1.4.2 QUERY FTP USER
This call will be used to find out information about a FTP user account. The
T_FTP_USER structure will be used for this call. The T_FTP_USER specific fields
are filled on output. The usage of the fields is as follows.
nCOMMAND: CMD_QUERY.
5.1.4.3 ALTER FTP USER
This call will be used to alter a FTP user definition. The T_FTP_USER_ALTER
structure will be used for this call. The T_FTP_USER_ALTER specific fields are
filled on input.
struct T_FTP_USER_ALTER{
struct T_FTP_USER FtpUser;
char szNewUserName[128];
BOOL bPasswordChanged;
};
The usage of the fields is as follows.
nCOMMAND: CMD_ALTER.
szUSERPASSWORD: The new password for the user. Valid if bPasswordChanged is
True. This value is filled on input.
szNEWUSERNAME: Holds the new user name for the FTP account. This value is filled
on input.
bPASSWORDCHANGED: Defines whether password has been changed or not. This value
is filled on input.
5.1.4.4 DELETE FTP USER
This call will be used to delete a FTP User. The T_PERL_INTF structure will be
used for this call. The usage of the fields is as follows.
nCOMMAND: CMD_DELETE.
17
5.1.5 MAIL USER INTERFACE
The management of Mail users will require the use of structure T_MAIL_USER.
Although the admin user can be setup and altered by altering the domain
information, it is recommended that this channel be used to alter information
about admin user as well. This structure will be used for the commands Create,
Query and Alter.
struct T_MAIL_USER{
struct T_PERL_INTF PerlIntf;
BOOL bForwarding;
BOOL bAutorespond;
char szAutoMessage[256];
char szForwardList[1024];
};
The usage of the fields is as follows.
eSERVERTYPE: SERVER_USER_FTP.
bFORWARDING:
bAUTORESPOND: Enables/Disables auto respond for the given user.
szAUTORESPOND: Holds the auto respond message. The value is valid if the field
bAutorespond is True,
szFORWARDLIST: Holds the forwarding list.
5.1.5.1 CREATE FTP USER
This call will be used to create a FTP user account. The T_FTP_USER structure
will be used for this call. The T_FTP_USER specific fields are filled on input.
The usage of the fields is as follows.
nCOMMAND: CMD_CREATE.
5.1.5.2 QUERY FTP USER
This call will be used to find out information about a FTP user account. The
T_FTP_USER structure will be used for this call. The T_FTP_USER specific fields
are filled on output. The usage of the fields is as follows.
nCOMMAND: CMD_QUERY.
5.1.5.3 ALTER FTP USER
This call will be used to alter a FTP user definition. The T_FTP_USER_ALTER
structure will be used for this call. The T_FTP_USER_ALTER specific fields are
filled on input.
struct T_MAIL_USER_EDIT{
struct T_MAIL_USER MailUser;
char szNewUserName[128];
int bPasswordChanged;
};
The usage of the fields is as follows.
nCOMMAND: CMD_ALTER.
szUSERPASSWORD: The new password for the user. Valid if bPasswordChanged is
True. This value is filled on input.
szNEWUSERNAME: Holds the new user name for the FTP account. This value is filled
on input.
bPASSWORDCHANGED: Defines whether password has been changed or not. This value
is filled on input.
5.1.5.4 DELETE FTP USER
This call will be used to delete a FTP User. The T_PERL_INTF structure will be
used for this call. The usage of the fields is as follows.
nCOMMAND: CMD_DELETE.
18
5.2 INTERFACE WITH SERVERS
The interface with servers is primarily in the form of updating files. The
authorisation for changing files must be checked separately as the process will
run as the root user process and will not need any further authorisation to make
the changes. To this effect, all data structures will carry the admin user
password (account user password in certain cases) to ascertain the validity of
each request. Once the request has been password checked, the request will be
handed to a root level process which will make the necessary changes.
Another issue which is critical here and will require a lot of effort is that
certain processes will need to be reinitialised. The restart process itself may
fail and would need a separate arrangement to ensure restart. An alarm will have
to be raised if the system is unable to restart a server properly within a
specified amount of time.
Finally, a separate thread will be set up to constantly monitor the
configuration files. This will guard against a user manually editing the files.
If the file is manually edited, this thread will notice the change to file and
restart the necessary servers.
19
5.3 SQL INTERFACE
The SQL table structures along with the changes of field values will constitute
the SQL interface. Any other program that needs to coordinate with the
provisioning system will monitor these tables and use them. Aside from the
common tables, which form the interface with other programs, some private tables
will also be used. Their structures will not be discussed in this section.
The tables will be designed and maintained with the following requirements in
mind.
- Any changes to a record should not merely overwrite old data, but the old
data must get backed up before being overwritten.
- There should be minimum possible data duplication. This means that one
piece of information should be stored at one place only (This does not
include data mirroring).
- Full time stamp and user information should be maintained for all changes
made to the configuration. User information may be redundant in some cases.
- Auto-increment integers are to be used as keys.
- The database will be mirrored and this might become an important factor in
table design.
5.3.1 CURRENT DESIGN AND IMPORTANT CONCEPTS
A preliminary design has been made with these guidelines in mind. This design
has been explained over the next few sections. The design has certain common
features, which help all tables behave in a similar manner and allow the
developer to achieve the same functionality from all tables.
Two important concepts that need to be explained before looking at table design
are record updates and record backups.
RECORD UPDATES refer to a change made to a record by the user. Once the user has
demanded a change, the actual change will involve backing up the existing record
(explained next) and writing the new values to the database. The updates to the
new record do not end with this process. Beyond this point, various flags will
be maintained and altered as individual tasks are performed and marked as
completed. The alterations to flags are changes to record, but will not be
included when we refer to record updates.
BACKUP PROCEDURE for a record involves creating a new record and copying all
values of the old record to the new record (except the key). The new record key
is then copied to the old record's PREVIOUS_RECORD field. The new values can now
be written to the old record. At this stage, we have all references pointing to
the altered version of the record and proper listing of the previous state of
the record.
5.3.2 FIELD USAGE
The usage of common fields is explained below.
DOMAIN_KEY: Holds the primary key of the domain. For all server level records,
this will be the only candidate for primary key.
ALTER_TIME: This is time stamp of time when the record was created or updated.
PREVIOUS_RECORD: Holds the key of the previous amendment to this record. If no
previous amendment exists, then this field is NULL.
STATUS: Value ranges
-1: Record Deleted.
1-49: Setup under progress.
50: Setup completed.
51-99: Billing under progress.
100: Billing completed.
20
5.3.3 TABLES
5.3.3.1 TABLE DOMAIN
This table will hold the current status of each domain. The table creation SQL
is
CREATE TABLE DOMAIN (
DOMAIN_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
DOMAIN_NAME CHAR(32) NOT NULL,
// BILLING_INFO
CREATE_MODE INT NOT NULL,
BILLING_MODE INT NOT NULL,
CARD_OWNER CHAR(64) NULL,
CARD_TYPE INT NULL,
CARD_NUMBER CHAR(16) NULL,
CARD_EXPIRY_DATE DATE NULL,
// DEMOGRAPHIC_INFO
LAST_NAME CHAR(64) NULL,
FIRST_NAME CHAR(64) NULL,
MIDDLE_NAME CHAR(64) NULL,
RES_ADDRESS_1 CHAR(64) NULL,
RES_ADDRESS_2 CHAR(64) NULL,
RES_CITY CHAR(32) NULL,
RES_STATE CHAR(4) NULL,
RES_ZIP CHAR(12) NULL,
RES_PHONE CHAR(32) NULL,
COMPANY_NAME CHAR(64) NULL,
BUS_ADDRESS_1 CHAR(64) NULL,
BUS_ADDRESS_2 CHAR(64) NULL,
BUS_CITY CHAR(32) NULL,
BUS_STATE CHAR(4) NULL,
BUS_ZIP CHAR(12) NULL,
BUS_PHONE CHAR(32) NULL,
BUS_EMAIL CHAR(64) NULL,
SEX INT NULL,
AGE INT NULL,
MARITAL_STATUS INT NULL,
NUM_CHILDREN INT NULL,
ANNUAL_INCOME INT NULL,
INET_FREQ INT NULL,
INET_USE INT NULL,
INET_USE_TEXT CHAR(64) NULL,
WHERE_HEAR INT NULL,
WHERE_HEAR_TEXT CHAR(64) NULL,
// TEMPORARY INFO
DOMAIN_CHOICE_TWO CHAR(32) NULL,
DOMAIN_CHOICE_THREE CHAR(32) NULL)
21
5.3.3.2 TABLE VIRTUAL WEB SERVER
This table will hold the current status of domain Virtual web server. The table
creation SQL is
CREATE TABLE VIRTUAL_WEB (
DOMAIN_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
DISK_SPACE INT NOT NULL,
BANDWIDTH INT NOT NULL,
CGI INT NOT NULL,
FRONTPAGE INT NOT NULL,
ANONYMOUS_FTP INT NOT NULL,
SECURE_KEY INT NOT NULL,
PERSONAL_SECURE_KEY INT NOT NULL,
WRITE_LOG INT NOT NULL,
BACKUPS INT NOT NULL,
STATISTICS INT NOT NULL)
5.3.3.3 TABLE MAIL SERVER
CREATE TABLE MAIL_SERVER (
DOMAIN_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
MAIL_BOXES INT NOT NULL)
22
5.3.3.4 TABLE USER
The table User registers a user for the domain. This is the common place to
register users both for FTP and mail servers. A user registered here can then
have accounts defined for FTP and Mail servers.
CREATE TABLE USER (
DOMAIN_KEY INT NOT NULL, // Primary Key
USER_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
NAME CHAR(32) NOT NULL,
PASSWORD CHAR(16) NOT NULL)
5.3.3.5 TABLE FTP USER
This table defines a FTP account for the user specified by the primary keys.
CREATE TABLE FTP_USER (
DOMAIN_KEY INT NOT NULL, // Primary Key
USER_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
ACCESS_LEVEL INT NOT NULL)
5.3.3.6 TABLE MAIL USER
This table defines the mail account for the user specified by the primary keys.
CREATE TABLE MAIL_USER (
DOMAIN_KEY INT NOT NULL, // Primary Key
USER_KEY INT NOT NULL, // Primary Key
PREVIOUS_RECORD INT NOT NULL,
ALTER_TIME TIMESTAMP NOT NULL,
STATUS INT NOT NULL,
FORWARDING INT NOT NULL,
AUTORESPOND INT NOT NULL,
AUTORESPOND_MESSAGE CHAR(256) NULL,
FORWARDING_LIST CHAR(1024) NULL)
23
6 DATA STRUCTURES
typedef T_Cmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
};
typedef T_UserNameCmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
char szUserName[32];
char szPassword[16];
char szOldUserName[32];
char szOldPassword[16];
};
typedef T_DomainNameCmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
char szNewDomainName[32];
BOOL bRegisterName;
};
typedef T_DNS_Cmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
char szPrimaryNameServer[64];
char szSecondaryNameServer[64];
BYTE pWebServerAddress[4];
};
24
Virtual Web server needs to send additional data only when information about a
user has changed. The following structure is used only for user level calls,
typedef T_VirtualWebServerCmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
char szUserName[32];
char szPassword[16]; //Filled only when password has changed.
};
Incoming mail server needs to send additional data only when information about a
user has changed. The following structure is used only for user level calls,
typedef T_IncomingMailServerCmd
{
word wVersion;
int nSize;
char szDomainName[32];
int nCommand;
char szOldUserName[32];
char szNewUserName[32];
BOOL bEnableAutorespond;
BOOL bEnableForwarding;
};
25
7 CLASS STRUCTURES AND PSEUDOCODE
Note: Both ServerInteface and RequestServer classes will need the ability to
open and manage sockets. Although provisioning servers do not need to
open server sockets, but once the sockets are open, the data
transmission code will be the same. It may be felt necessary to join
these two classes at a higher level (or provide a friend class) to
handle sockets.
7.1 SERVERINTERFACE (BASE CLASS)
class ServerInterface
{
private:
void WriteLog(LPSTR szDomainName);
LPBYTE LocateMachine(LPSTR szDomainName);
LPVOID InitBuffer(int nBufSize);
int CreateRequest(LPBYTE IPAddress);
int EditRequest(LPBYTE IPAddress);
int DeleteRequest(LPBYTE IPAddress);
protected:
// These variables are dependent on the derived classes and will be
initialised in their constructors.
ServerType eType; // The type of server this instance will call.
int nCreateSize; // Data block size for Create Buffer.
int nEditSize; // Data block size for Edit Buffer.
int nDeleteSize; // Data block size for Delete Buffer.
// All of these functions will be upgraded in derived classes.
void WriteCreateLog(LPSTR szDomainName);
void WriteEditLog(LPSTR szDomainName);
void WriteDeleteLog(LPSTR szDomainName);
int UpdateCreateBuffer(LPVOID pBuffer);
int UpdateEditBuffer(LPVOID pBuffer);
int UpdateDeleteBuffer(LPVOID pBuffer);
public:
ServerInterface(void);
~ServerInterface(void);
int CreateEntry(LPSTR szDomainName);
int EditEntry(LPSTR szDomainName);
int DeleteEntry(LPSTR szDomainName);
}
The calling order for functions of this class will be as follows.
1. Construct class.
2. Write Create/Edit/Delete Log. (Complete this write log operation for all
tasks in the current transaction).
3. Create/Edit/Delete Entry.
4. Destroy.
It is important to write all logs before making any server call so that data
provided by user does not get lost due to some glitch and in the worst case will
get processed by the failed task queue.
ServerInterface::ServerInterface(void)
Default Constructor.
ServerInterface::~ServerInterface(void)
Default Destructor.
26
void ServerInterface::WriteLog(LPSTR szDomainName)
This common routine is called by all logging functions. This function
creates a logging record, assigns the time stamp.
LPBYTE ServerInterface::LocateMachine(LPSTR szDomainName)
Locates IP Address of machine hosting the service for given Domain.
LPVOID ServerInterface::InitBuffer(int nBufSize)
Allocates memory for data buffer and initialises memory with basic
information like data block size, version number etc.
int ServerInterface::CreateRequest(LPBYTE IPAddress)
Calls InitBuffer, UpdateCreateBuffer and transmits to specified address.
int ServerInterface::EditRequest(LPBYTE IPAddress)
Calls InitBuffer, UpdateEditBuffer and transmits to specified address.
int ServerInterface::DeleteRequest(LPBYTE IPAddress)
Calls InitBuffer, UpdateDeleteBuffer and transmits to specified address.
void ServerInterface::WriteCreateLog(LPSTR szDomainName)
Calls WriteLog and marks log as Create log.
void ServerInterface::WriteEditLog(LPSTR szDomainName)
Calls WriteLog and marks log as Edit log.
void ServerInterface::WriteDeleteLog(LPSTR szDomainName)
Calls WriteLog and marks log as Delete log.
int ServerInterface::UpdateCreateBuffer(LPVOID pBuffer)
Called by CreateRequest to update transmit buffer with Create command.
Derived classes will add more details to the structure.
int ServerInterface::UpdateEditBuffer(LPVOID pBuffer)
Called by EditRequest to update transmit buffer with Edit command. Derived
classes will add more details to the structure.
int ServerInterface::UpdateDeleteBuffer(LPVOID pBuffer)
Called by DeleteRequest to update transmit buffer with Delete command.
Derived classes will add more details to the structure.
int ServerInterface::CreateEntry(LPSTR szDomainName)
This is the generic create routine. It performs all common tasks for new
domain to be registered with a server. These tasks will include
- Locating task on queue.
- Checking dependencies.
- Connect to server.
- Negotiate Version.
- Making a create call to server.
- Close Connection.
- Flagging task as completed.
Returns zero on success. Negative values on error. Positive values indicate
success, and also some associated condition.
int ServerInterface::EditEntry(LPSTR szDomainName)
This is the generic edit routine. It performs all common tasks to edit a
service parameters associated with a domain. These tasks will include
- Locating task on queue.
- Making sure that the domain to be altered exists on this server.
27
- Ensuring that there are no previous edits pending for the domain.
- Connect to server.
- Negotiate Version.
- Making a edit call to server.
- Close Connection.
- Flagging task as completed.
Returns zero on success. Negative values on error. Positive values indicate
success, and also some associated condition.
int ServerInterface::DeleteEntry(LPSTR szDomainName)
This is the generic delete routine. It performs all common tasks to delete
a service for the specified domain. These tasks include
- Locating task on queue.
- Making sure that the domain to be altered exists on this server.
- Connect to server.
- Negotiate Version.
- Making a edit call to server.
- Close Connection.
- Flagging task as completed.
Returns zero on success. Negative values on error. Positive values indicate
success, and also some associated condition.
7.2 USERNAMEINTERFACE (DERIVED CLASS)
class UserNameInterface: public ServerInterface
7.3 DOMAININTERFACE (DERIVED CLASS)
class DomainInterface: public ServerInterface
7.4 DNS_INTERFACE (DERIVED CLASS)
class DNS_Interface: public ServerInterface
7.5 VIRTUALWEBINTERFACE (DERIVED CLASS)
class VirtualWebInterface: public ServerInterface
7.6 INCOMINGMAILINTERFACE (DERIVED CLASS)
class IncomingMailInterface: public ServerInterface
28
7.7 REQUESTSERVER (BASE CLASS)
class RequestServer
{
private:
int CheckVersion(LPVOID pBuffer);
int InterpretCommand(LPVOID pBuffer);
protected:
// These variables are dependent on the derived classes and will be
initialised in their constructors.
ServerType eType; // The type of server this instance will call.
int nMaxMajorVersion; //Maximum version number supported.
int nMaxMinorVersion; //Maximum version number supported.
int nMinMajorVersion; //Minimum version number supported.
int nMinMinorVersion; //Minimum version number supported.
int CreateCommand(LPVOID pBuffer) = 0;
int EditCommand(LPVOID pBuffer) = 0;
int DeleteCommand(LPVOID pBuffer) = 0;
void UpdateServerPriority(void) = 0;
public:
RequestServer(void);
~RequestServer(void);
};
RequestServer::RequestServer(void)
Constructor starts the socket to listen for incoming requests.
RequestServer::~RequestServer(void)
Shuts down the listening socket.
int CheckVersion(LPVOID pBuffer)
Check the major and minor version numbers of the data in the buffer.
Returns a negative number in case of error.
int InterpretCommand(LPVOID pBuffer)
Forks to appropriate function (Create/Edit/Delete Command) depending
on the command in the buffer. On successful completion, calls
UpdateServerPriority.
int CreateCommand(LPVOID pBuffer)
A function stub that will be implement as the actual Create command.
int EditCommand(LPVOID pBuffer)
A function stub that will be implement as the actual Edit command.
int DeleteCommand(LPVOID pBuffer)
A function stub that will be implement as the actual Delete command.
29
7.8 USERNAMESERVER (DERIVED CLASS)
class UserNameServer: public RequestServer
{
protected:
int CreateCommand(LPVOID pBuffer);
int EditCommand(LPVOID pBuffer);
int DeleteCommand(LPVOID pBuffer);
void UpdateServerPriority(void);
public:
UserNameServer(void);
};
UserNameServer::UserNameServer(void)
- Calls base class handler.
- Sets up base class protected variables.
int UserNameServer::CreateCommand(LPVOID pBuffer)
- Create an internal user name using the name provided and the domain
name.
- Create a login with the generated user name and the password.
int UserNameServer::EditCommand(LPVOID pBuffer)
- Reconstruct internal user name.
- Make necessary account changes.
int UserNameServer::DeleteCommand(LPVOID pBuffer)
- Reconstruct internal user name.
- Delete the login.
7.9 DOMAINSERVER (DERIVED CLASS)
class DomainServer: public RequestServer
{
protected:
int CreateCommand(LPVOID pBuffer);
int EditCommand(LPVOID pBuffer);
int DeleteCommand(LPVOID pBuffer);
void UpdateServerPriority(void);
public:
DomainServer(void);
};
DomainServer::DomainServer(void)
- Calls base class handler.
- Sets up base class protected variables.
int DomainServer::CreateCommand(LPVOID pBuffer)
- Check for availability of the domain name (should be available).
- Prepare the mail message.
- Send the message with one copy sent to a local address for record.
- Associate the domain name with the current account.
int DomainServer::EditCommand(LPVOID pBuffer)
- Check for availability of domain name (should not be available)
- Call create command to register doamin name.
- Associate new domain name with current record.
- Return warning if the domain points to some other DNS server.
int DomainServer::DeleteCommand(LPVOID pBuffer)
- Remove domain name association with account.
30
7.10 DNS_SERVER (DERIVED CLASS)
class DNS_Server: public RequestServer
{
protected:
int CreateCommand(LPVOID pBuffer);
int EditCommand(LPVOID pBuffer);
int DeleteCommand(LPVOID pBuffer);
void UpdateServerPriority(void);
public:
DNS_Server(void);
};
DNS_Server::DNS_Server(void)
- Calls base class handler.
- Sets up base class protected variables.
int DNS_Server::CreateCommand(LPVOID pBuffer)
- Append a primary entry to the file /var/named/named.boot
- Create a directory named DO on the path "/var/named" if the directory
is not present.
- Create a file named XXXXXX.XXX on this path.
- Fill up the file with the basic information.
int DNS_Server::EditCommand(LPVOID pBuffer)
- If : domain name has changed, run the delete and create commands.
- Else: Make changes to XXXXXX.XXX file and increment the count.
int DNS_Server::DeleteCommand(LPVOID pBuffer)
- Delete old entry from "named.boot" file.
- Delete XXXXXX.XXX file.
7.11 VIRTUALWEBSERVER (DERIVED CLASS)
class VirtualWebServer: public RequestServer
{
protected:
int CreateCommand(LPVOID pBuffer);
int EditCommand(LPVOID pBuffer);
int DeleteCommand(LPVOID pBuffer);
int AddUser(LPVOID pBuffer);
void UpdateServerPriority(void);
public:
VirtualWebServer(void);
};
VirtualWebServer:: VirtualWebServer (void)
- Calls base class handler.
- Sets up base class protected variables.
int VirtualWebServer::CreateCommand(LPVOID pBuffer)
-
int VirtualWebServer::EditCommand(LPVOID pBuffer)
-
int VirtualWebServer::DeleteCommand(LPVOID pBuffer)
-
int VirtualWebServer::AddUser(LPVOID pBuffer)
-
31
7.12 INCOMINGMAILSERVER (DERIVED CLASS)
class IncomingMailServer: public RequestServer
{
protected:
int CreateCommand(LPVOID pBuffer);
int EditCommand(LPVOID pBuffer);
int DeleteCommand(LPVOID pBuffer);
int AddUser(LPVOID pBuffer);
void UpdateServerPriority(void);
public:
IncomingMailServer(void);
};
IncomingMailServer:: IncomingMailServer (void)
- Calls base class handler.
- Sets up base class protected variables.
int IncomingMailServer::CreateCommand(LPVOID pBuffer)
- Create the directories.
- Setup the links
- Create necessary files
- Make additions to mailer_table and xxxxxxxx.xX files.
- Run makemap and HUP sendmail.
int IncomingMailServer::EditCommand(LPVOID pBuffer)
- Make changes to files .forward, .autorespond and .deliver.
- Run makemap and HUP sendmail.
int IncomingMailServer::DeleteCommand(LPVOID pBuffer)
- Delete the directory /path_to_toaster/domain_name.
int VirtualWebServer::AddUser(LPVOID pBuffer)
7.13 FAILED TASK QUEUE
This is a separate process which may or may not run on the provisioning
computer. This process will cycle through the list of failed tasks and do the
following steps
- Identify the server to be contacted.
- Send request to the server.
- Update log if request succeeds.
This process will run a separate thread to manage server prioritisation. A
server's priority is decided by server rating (calculated as a weighted sum of
all resources on the server) and a multiplier. This multiplier is set to 10 for
a normal functioning server. When a task on a server fails, this multiplier is
set to 0. The server prioritisation thread is a thread which sleeps most of the
time and at regular intervals wakes up to increment the priorities which are
less than 10.
7.14 MACHINE ALLOCATION FOR NEW/ALTERED DOMAIN.
A simple function. Accesses the server priority information for the given server
type and returns the highest priority server.
7.15 DOMAIN IS AVAILABLE
Returns true if domain registration can be attempted. The registration id not
guaranteed to succeed.
- Run "whois" to find out whether the domain is already registered by
InterNIC.
- Check local database to confirm that the domain name is not being processed
for some other user.
32
7.16 DOMAIN REGISTRATION CONFIRMATION BY INTERNIC
The actual mail will be read manually. The information coming to this module
will be used to flag the log as either completed or failed.
7.17 CHECK USER INFO FOR EMPTY FIELDS
This module will check all critical fields (like password, user name etc.) for
completeness.
7.18 CHECK USER INFO FOR INVALID DATA
This module will check user data for validity eg. Both passwords must match,
user name size limits etc.
7.19 SAVING AND RETRIEVING DEMOGRAPHIC INFORMATION.
Write demographic information to database and retrieve from database on basis of
user key.
7.20 MAKING BILLING ENTRIES.
This function will be called by provisioning server after a transaction is
logged. This module will make non-accounting entries only.
7.21 ADMINISTRATION INTERFACE
This is a low priority module which will give the administrators a way to send
commands to the provisioning system. This will have added features to show
administrators the current status of the system, failed task queue etc.
33
8 TERMINOLOGY
8.1 TRANSACTION
A transaction is a user request where a user provides a form load of data and
asks for the data to be processed. A example of a transaction is User filling up
a form providing his login name, password, address, name, credit card number,
type of service he needs etc on form and sending it for processing.
8.2 TASKS
The transaction described above can be broken down into one or more tasks like
- Creating the user login
- Setting up the POP mail account.
- Setting up the Web page
In the system, the tasks will be broken down into critical tasks (eg. Creating
user login) which must be completed for the transaction to be considered
successful and other tasks that can fail at the time of running the transaction,
but can be completed later.
8.3 PROVISIONING SERVER
Provisioning server is the server that will support domain setup and management
utilities. Ideally it will be one or more machines running the provisioning
software. This server will talk to other servers viz. DNS, FTP, POP etc and set
them up as per the user requirements.
8.4 SERVERS
The term "servers" has been used to refer to servers other than the provisioning
server. These servers will be DNS, Incoming mail and Virtual Web Server.
Actually, there will be multiple machines providing each of these services. The
provisioning machines not only need to decide which type of server to talk to,
but also which specific machine to talk to. The provisioning servers will then
pass on the user requests to these machines which in turn will actually process
them.
8.5 USER
The user here is a person or entity who interacts with the system and initiates
a transaction. For example, someone who wants to set up a domain with FTP
facility and fills up the form necessary and presents is a user in this context.
POP : No action
FTP : Same to all machines
mail: same to all machines
virtual web : Number of virtuals in the confs.
34
