RNA Service Integration Design Document
Generic Database Service
Phase 2

Rationale: A database server running on an appliance still requires some administrative and initial configuration. This include initial "database" creation as well as user/permission accounts. This document describes our initial RNA interface to generic databases.

Introduction

Many customers are asking for "database services" for our server appliances. This includes both the ISP and the SBS server product variations. Both products need access through the "ASP" services we currently offer, i.e. PHP, JSP and CGI.

Normally, a database would live on a server that is separate from the servers that contain the application and presentation (Web) layers. However, for a server appliance we will need to come up with a way of putting all the tiers on a single server platform. Note: This is a key selling point for our Immunix security technologies.

The database service offering will be introduced to our OEM customers in a series of phases. This will allow us to be quick-to-market, get early customer feedback, and limit the expense to build.

• Phase 1 - Database installed and compatible with the current version of Apache, PHP and Tomcat.
  
  
• Phase 2 - Database with complete RNA administrative support. Although we may have interim phases before we get to the larger "Phase 3."
  
  
• Phase 3 - "Access-like" web interface to the database for online queries and report generation.

Phase 1 was complete with the ISP 2.0 product. Phase 3 is an ambitious project is beyond the scope of this document. This document will primarily describe "Phase 2."

Requirements

Phase 2 has the following engineering requirements. These are based on customer and marketing feedback as well as engineering wish-lists.

• Multiple Database Access. It is unclear which of the many database servers available for Linux should be used, e.g. MySQL is more popular and more well known, but lacks certain features, and Postgres, while less popular, is completely free and has more features, but not as fast. Oracle is popular and extremely feature rich, but is very costly for a server appliance. It is very possible that our customers will want all databases that are available. They will be driven by the server applications they wish to install. We will need to support as many as we can.
  
  We will have initial support for both Postgres and MySQL, and allow the user to create databases within either server.
  
  
• PHP/JSP/CGI Access. Dynamic, web-based scripts need access to the database server. This means the following:
  • PHP/Apache support via a mod_php module, etc.
  • JDBC module for the database server(s).
  • Perl DBD modules for the database server(s).
  Note: This was accomplished during Phase 1 for MySQL, but will need to be expanded for Postgres support.
  
  
• Unconsolable Support. The console program, unconsolable, needs to have access to starting/stopping the database server. This should be listed with the rest of the services and doesn't need anything extra.
  
  
• Control Panel Interface. The RNA control panel (listed under the "Services" menu) needs to have access to starting/stopping the database server. Like the console, this will be treated like any other service.
  
  
• Manage individual "databases". A database server will have a number of different "databases" that will potentially be owned by different people.
  
  
• Permission Accounts (Roles). Access to the database (and to individual tables) will be controlled by "roles." These roles will be created and managed through the RNA interface. Server applications will use one or more roles in order to access the database.
  
  Note: We should not confuse the issue of a "user account" with a database "permission account" (role) as the two should be separate for security reasons.
  
  
• No direct "table" support. This release phase will NOT allow the user to create or manipulate individual tables in a database. This is because PHP/JSP/CGI's can be run that do this.
  
  For instance, access from a JDBC (Java) enabled app is done by specifying the server (and the network port), the database on the database server and a role with a password. Once this access is made, it can create tables, add data and query the database.
  
  

Design Features

The RNA database service integration will follow standard development methods that have been previously employed. This section has two distinct parts: The top-level user interface and the underlying API that does the work of administrating database servers.

User Interface Design

This section describes the user interface design from the perspective of the menu structure placed under the Services menu. Each menu item listed references a "form sequence" described later.

Database Service Menu. The database service menu will contain the following structure:

• Configure Service. Which selects which database server to use (if multiple ones have been installed) and the DBA password and other information for a particular database (see Database Configure below).
  
  
• Manage Databases. A submenu that contains the following:
  
  
  • List Databases. Lists all the databases, the tables in the databases and the roles (with their permissions) for each database and/or table (see List Databases section below).
    
    
  • Create Database. Creates a database and optionally allows them to create some initial roles or permission accounts (see Create Databases section below).
    
    
  • Delete Database. A listing of all databases in all servers. Using "checkitem" elements, the user should be able to select a number of databases to delete (or drop).
  
  
  
• Manage Roles. This submenu will be similar to the virtual domains menu, in that we will list all of the databases that have been created, and then the following submenu under each one.
  
  
  • List Roles. Displays all roles for a particular database, similar to the table displayed under "List Databases" (except that this is localized for a particular database).
    
    
  • Add Role. First form allows entry of a role's "name" and password and a list box entry that allows the user to select all of the appropriate permissions.
    
    As with other commands, we will want to be able to have a database specific form that may contain special parameters/options for roles in a particular database.
    
    
  • Edit Role. First form would list all of the available roles. The second form would display the permissions in the form of a list box.
    
    This form would also have a radio button that queries whether the password for the role should be reset. If this is selected, a following form would query for the new password to be set. The RNA will not be required to figure out what the password is for a particular role.
    
    
  • Delete Role. The first form would list all of the available roles that will be deleted.
    
    
  
  
  

The first form will contain a listing of all database services available on the appliance. They will be listed in a series of "radioitem" elements with a short description of the advantages of the particular database. The user will select on database to continue. This initial form will display the status of each of the databases as to whether they are configured or currently running.

The second form will allow the user to set the DBA password for the database server.

We may detail other configuration values that are specific for the particular database server. We need a way for a "database-specific" form to be displayed.

Once the database is configured, it will be started (they will not initially be started immediately following installation).

This form will simply display a table of all the configured database servers, their databases, the tables, and the roles (with permissions) for each database/table. For instance:

The first form will have an initial field that specifies which of the configured database server the database should be created in. Note, if only one server has been configured, this field will not be displayed.

The first form will also allow the name of the database to be entered and checked for validity.

An initial role name (called DB Owner?) and password that will have ALL privileges to the database will be also on this first form.

An optional second form that is specific to a particular database may need to be displayed with the extra information given to the perl scripts for creating a database with special features (notice Oracle's variations of the CREATE DATABASE command).

Perl API Design

The RNA forms will eventually (after gathering user information) will call a perl script. These perl scripts will be designed using the new WireX Perl module structure. In other words, they will be simply shell wrappers that use "database-related" functions imported from a module.

We will create a WireX::DBAdmin module that contains a number of functions for accomplishing the tasks described in this document. Each function will take, as the first argument, a string that describes the database server to work with. For instance:

	WireX::DBAdmin::create_database("mysql", "customerX", "...");
    

Will simply be a wrapper for a MySQL-specific function located in another module, for example:

	WireX::DBAdmin::MySQL::create_database(...)
    

These modules will take advantage of our "Callback" infrastructure, however, these will not use the DOM config file modules since the database servers have a front-end command-line program that can be used for configuration.