Master of BIND (MoB)

0. About This Document

This document describes the requirements for the Master of BIND (MoB) component for BIND 10. It is based roughly on the SRS documented on the Wikipedia:

1. Introduction

BIND 10 will be a set of co-operating processes. There needs to be a process which starts these - that process is the MoB. The MoB will also be responsible for terminating processes and adding new processes at runtime.

2. Specific Requirements

2.1 External Interface Requirements

2.1.1 User Interfaces

The MoB will be started using as a normal Unix process. This can be done via the command line, shell script, or system init script.


    $ mob --c-channel-port=9913 --conf-db=/var/lib/bind10/conf.db --verbose
    BIND 10 v20091225 ("Shane's Christmas Present") booting
    Starting c-channel using port 9913
    Started c-channel with PID 3143
    Starting configuration daemon using "/var/lib/bind10/conf.db"
    Started configuration daemon with pid 3146
    Switching to normal BIND 10 logging

2.1.3 Software Interfaces

The normal BIND 10 mechanisms will be used for configuration, communication, and so on.

This may not be possible due to bootstrapping reasons. In this case, specialized or other mechanisms may be used. For example, if the logging configuration is not yet initialized, messages may be written to stdout/stderr.

2.1.4 Communication Protocols

Unix signals and process handling will be used. For administrative functionality, the BIND 10 c-channel will be used.

2.1.5 Memory Constraints

There must be no memory leaks. This means the process memory must be bounded over time, although adding new tasks to track will over course increase memory usage.

2.2 Software Product Features (or "Use Cases")

2.2.1 Startup

On startup, the component should check to see if an earlier version terminated badly. This can happen due to software error, or perhaps due to SIGKILL. If an earlier version had terminated, the software should see what, if any, other components are running and try to get the system into a usable state.

If the system is clean or no other components are running, the process should startup the following components:

  • c-channel
  • configuration daemon

It must be possible to specify alternate c-channel configuration or configuration daemon startup information on the command line.

It should use the normal configuration information to determine what other components to start.

2.2.2 Shutdown

To shutdown, the MoB executes a force-stop for each other component. (See below for details.)

2.2.3 Get current status

The MoB should return what components it has started, and what it thinks their status is. Some other status may be returned, even if this duplicates some stats maintained by the stats daemon.

2.2.4 Start new component

You can ask the MoB to start a new component.

In normal BIND 10 mode, this updates the configuration so that the component starts on every boot.

In "config file" BIND 10 mode, the component is only started for this instance. A warning must be issued alerting the administrator of this.

2.2.5 Stop a running component

You can ask the MoB to stop a component.

The component may refuse this request. The MoB, c-channel, and configuration daemon will all refuse this request.

2.2.6 Force-stop a running component

You can ask the MoB to stop a component, forcing it to do so.

The MoB asks the component to stop. If it either fails to respond, or take a long time (defaulting to 5 seconds but this must be configurable), then MoB will log a warning and kill the component.

2.2.7 Re-start failed component

If a component stops, the MoB must detect this and re-start the component.

2.2.8 Update stats

The MoB must periodically update the stats at the stats daemon, if the stats daemon is running.

2.2.9 Upgrade MoB

The MoB must be able to install a new version of itself without restarting the entire system.

2.2.10 Upgrade component

The MoB must be able to install a new version of any component. This may restart the component.

2.3. Software System Attributes

2.3.1 Reliability

The process must run until shutdown is requested.

The process should not fail on corrupt or invalid input.

Other reliability requirements are covered in the software product features (restart without shutdown and so on).

2.3.3 Security

The MoB will run for any user with Unix permissions to run it.

Access to specific functions will be restricted by normal BIND 10 mechanisms. These do not exist yet, but will likely involve ACL defining access to each function.

2.3.4 Maintainability

The MoB must be able to start components using older versions of initialization mechanisms.

Upgrades should be possible on a per-component basis. This is supported by the restart operations.

2.3.5 Portability

The MoB must run on any system that BIND 10 runs on.

2.3.6 Performance

All operations must return status within 1 second. Operations that take longer, like force-stop, will also return a completion status when done.

Last modified 9 years ago Last modified on Sep 23, 2009, 3:35:24 PM