How the Registry Database is Stored on Disk

Each registry server, whether master or slave, maintains a working copy of its database in virtual memory and a permanent copy on disk. All lookups and updates operate on the copy in virtual memory. The server uses the copy on disk to initialize the copy in memory when it starts up.

When a master server receives an update from a utility such as edrgy or when a slave server receives an update from the master, the server applies the update to its database in virtual memory and also saves the update in a log file on disk. Updates accumulate in this log file in chronological order. When a server restarts (for example, when a server node boots), it initializes its database in memory from the database on disk and then it "replays"

the updates from the log file. This mechanism ensures that no updates are lost when a server node is shut down.

Each registry server periodically saves its entire database from virtual memory to disk. The database is stored in the directory Isys/registry. When it performs a disk save, the server clears the log file.

Sections 4.8, "Routine Maintenance" and 4.10, "Troubleshooting," give procedures for backing up the registry database and for restoring the database from a backup tape.

In Subsection 4.6.3, you must choose one of two procedures, depending on whether you are creating a new network of nodes running SR10 or updating an existing network from SR9 to SR10.

The procedures in Subsections 4.6.5 and 4.6.8 might not be necessary at your site. All other procedures in this section are essential to successful operation of the registry.

If you are creating a Domain internet, you should see Managing Domain Routing and Domain/OS in an Internet for more information.

4.6.1 Planning a Configuration

Use the following considerations to plan a configuration of registry servers for your site:

• You can run more than one rgyd on a network. In an internet, we recommend that you run at least one rgyd in every network.

• Nodes that run rgyd should have local disks. They also should have at least 3 MB of physical memory, more for very large registries.

• Nodes that run rgyd should be running and available all the time. It is especially important that the node where the master server runs be available throughout the network or internet.

Choose a site for the master server. If you decide to run several servers, choose sites for the slave servers.

4.6.2 Starting Location Brokers

Before you run registry servers, you must establish Location Brokers on your network. At least one Global Location Broker (glbd) must run on your network. In an internet, at least one glbd must run on each network of the internet. A Local Location Broker (llbd) must run on every node that runs a glbd and on every node that will run a registry server

(master or slave).

Managing the NCS Location Broker gives procedures for starting up Location Brokers.

Refer to this manual now and then continue with Subsection 4.6.3.

4.6.3 Creating the Registry Database

There are two ways to create an SR10 registry database.

Updating an SR9 Registry to SRI0

If you are updating from SR9 to SR10 system software on your network or internet, you should convert your SR9 registry database to SR10 format via the cvtrgy utility. Skip the rest of this subsection, follow the conversion procedures described in Making the Transi-tion, then proceed with Subsection 4.6.4.

Setting Up a New SRI0 Registry

If you are setting up a new network or internet of Domain nodes and SR10 Dpmain/OS is the only system software any of these nodes have ever run, you use the rgy _create utility to create a new database and initialize it with reserved names and accounts. You typically create the SR10 registry as part of your first SR10 installation. Since it is used only once, rgy_create resides in the /install/tools directory and is not included in subsequent SR10 installations. See Installing Software with Apollo's Release and Installation Tools for more information about rgy_create.

4.6.4 Starting the Master Registry Server

Log in on the master registry site node and use Ibin/ps or Icom/pst to verify that an llbd is running on the node.

To start the master server, complete the following steps:

1. Become root and enter the following command on the master node:

$ /etc/server -p /etc/rgyd &

The -p option causes fete/server to create a process that runs under the SID that invoked the command, rather than the default of user. server. none.

2. Create the file letc/daemons/rgyd on that node, so that the server will start each time the system boots. Use the UNIX toueh command or the Aegis crf command:

$ touch /etc/daemons/rgyd

$ erf letc/daemons/rgyd

4.6.5 Establishing Uniform UNIX Numbers

(UNIX environments) (Aegis)

If your Apollo systems share files with other UNIX systems, you should ensure that names, UNIX IDs, and account information are consistent between the Domain/OS registry and the foreign passwd and group files. For the purposes of this discussion, "file sharing" can take the form of direct access through facilities such as Domain NFS or indirect file trans-fer via media such as tar tapes.

We provide a tool called import_passwd that helps you to identify and resolve conflicts of names, UNIX IDs and account information. If you plan to share files between Apollo systems and other UNIX systems, we recommend that you run import_passwd now to minimize the number of changes you have to make. Typically, you run import_passwd in a mode that changes IDs in the Apollo registry to match the IDs on the foreign systems;

afterward, you will have to run another tool called syncids to ensure that the IDs stored in Apollo file systems match those stored in the registry.

See Section 4.11 for detailed information about import_passwd.

We provide default passwords for all reserved accounts except user. none. none, which by default has no password. These defaults are set either by cvtrgy (if you converted from an SR9 registry) or by rgy_create (if you created a new SR10 registry). You should use edrgy to change or set the passwords for these accounts.

Now is also the best time to change the owners of reserved registry data, if you do not want to use the defaults. See Subsection 4.2.7 for details.

4.6.7 Adding Names and Accounts

Your registry now contains the following names and accounts:

• Those added as reserved information by rgy_create or cvtrgy

• If you used cvtrgy, those derived from your SR9 registry

• If you used import_passwd, those derived from the password and group files on your other UNIX systems

Use edrgy to add any other names and accounts that your site requires. You can do this now or at any time later.

4.6.8 Creating Slave Registry Replicas

Follow the procedures in this subsection if you want to replicate the registry database.

1. Log in on a slave node and use Ibin/ps or Icom/pst to verify that an Ilbd is run-ning on the node.

2. To start the slave server, become root and enter the following command on the

slave node: ~

$ letc/server -p letc/rgyd -create

~

This command locates the master server, adds the local node to the master replica list, and causes the master to initialize a new database at the local node.

3. As you did on the master node, create the file letc/daemons/rgyd, so that the server will start each time the system boots. Use touch or crf:

$ touch letc/daemons/rgyd (UNIX environments)

$ crf letc/daemons/rgyd (Aegis)

4. Repeat the above steps for each replica you want to create.

You can use the lrep -state command in the rgy_admin tool to verify that the master and slave servers are running.

4.6.9 Restarting Registry Servers

To restart a registry server, whether a master or a slave, run rgyd without any options:

$ letc/server -p letc/rgyd&