From ImageWeb

Contents 1 ADMIRAL support for multiple research groups 1.1 Problem statement 1.2 Proposed strategy 1.3 System build scripts 1.4 Test suite changes 1.5 Build new system

ADMIRAL support for multiple research groups

Problem statement

Having multiple test suites for different research groups, not only leads to redundancy but also incurs additional maintenance of separate test suites for different user groups. Tests changed at one place need a change in all the copies and is time consuming. We prefer that a single test suite can be used for all ADMIRAL system user groups.

Proposed strategy

1. Revise the file structure so that same tests can be used with all the research group systems (e.g. /private, /shared, /collab, /public). This will allow different security policies can be achieved by each research group using different parts of a commonly configured file system. The test suite can be written to run against the common configuration.
2. Security policy details are currently handled, in part, by the scripts used to add new research group users to the system. We want to have a per-research-group configuration that allows the add-user scripts to be varied for each research group, with most files being common to all research groups.
3. Thus, for each research group, create a separate directory in admiral-base, named for the Research group, containing:
   • files that differ from those in admiral-base
   • per-group config parameters except passwords
   • Revise copywithhostandpassword.sh (and rename?) to merge research group specific files with the common base.

If we use the pattern of directories /private/username, /shared/username, /collab/username, /public/username for the differently protected file areas, the current Silk Group deployment (which uses /username for private files) is no longer compatible with this regime. A quick fix in this case could be to create symlinks from /username to /private/username. (This pattern might be generalized to accommodate different default protection for user's files.)

System build scripts

1. Create a set of group-specific configuration files for the test server
2. Create a copy of copywithhostandpassword.sh named makeresearchgroupfiles.sh that performs essentially the same function, but also merges additional group-specific files from a named subdirectory.
3. Move the configuration data (except passwords) from being command line arguments to a configuration file in the group-specific directory. Thus, when running makeresearchgroupfiles.sh, the only command line parameters needed should be the research group name an the system password.

Test suite changes

1. Enhance the test suite to include tests for the new file layout (am considering reorganizing the tests to make this easier)

Build new system

1. Create group-specific configuration files for alternative security model.
2. Generate new system
3. Deploy new system in KVM test environment
4. Run test suite against new system