This chapter describes how to use the dmu utility to manage Dataless Management Services (DMS) environments and clients. The information in this chapter describes how to:
The information you need to add a DMS client is shown in the Client Setup Worksheet in Appendix B. You should fill out a worksheet for each client you want to add before you use dmu to add clients to a DMS environment.
Before you can add a client, you must have already followed the procedures in Chapter 11 to install software in at least one DMS environment, and customize the .proto.. files (if desired).
The client system must be connected to a Local Area Network (LAN) and must be registered with the server through one of the network naming services (see Section 10.8) or must have an entry in the server's /etc/hosts file.
When a client is added to a DMS environment, the root directory from the server's DMS environment gets copied to the client area.
Use the following procedure to add a client to a DMS environment:
#
/usr/sbin/dmu
*** DMU Main Menu ***Enter your choice: a
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
You have chosen to add a client for dataless service.
The following conditions must be met to add a client:
1. You must know the client processor's hostname. 2. The client's hostname must be in your system's host database(s). 3. You must know the client's interface type, subnet mask. 4. You must know the type of kernel build area. 5. You must know the swap device and partition on the client. 6. You must know the client's hardware Ethernet or FDDI address. 7. If the client and the server reside on different subnets, you will need the address of the gateway(s) that the client can sue to communicate with the server.
Do you want to continue? (y/n) [y]:
If you enter n, the dmu utility returns to the DMU Main Menu. If you enter y or press the Return key (to accept the default), the utility prompts you to enter the client's host name.
The following are the known gateway[s] between the client
subnet and server subnet. If these values[s] are not correct,
please enter the proper addresses[s].
If these values are correct press Return.
( For example, 16.69.144.???):
[16.69.144.199]
Enter the client's route for network address as shown in the following example:
Enter the IP address of the gateway[s] between the client
subnet and server subnet:
( For example, 16.69.144:???):
[16.69.144.199]
Enter the client processor's hostname or press RETURN to quit:
client1
If you press the Return key, the utility returns to the DMU Main Menu. If you enter a host name that is not in the server's host database, the following message is displayed:
arp failed on hostname "client_name"
In the above message, arp is the address resolution protocol. If you receive this message, check the server's host database, the /etc/hosts file, to determine the correct client name. If the client was never registered with a network naming service (such as BIND or NIS) or was never entered in the /etc/hosts file, exit the utility by pressing Ctrl/c and add the client to the /etc/hosts file.
Note
For the remaining examples, assume the Return key is pressed to accept the default response.
Enter the path to the client's root file system at the prompt:
Enter the path to contain the root file system.
[/clients/client1]:
Enter the swap device and partition on client1. [rz0b]:
Enter the swap device drive type for rz0b. [RZ26]:
Enter the network interface for client1 (16.69.199.157) [ln0]:
Enter the subnet mask for ln0. [255.255.255.0]:
Enter the default route for network 16.69.224 [16.69.144.199]:
If no entry for the client's subnet is found in the /var/adm/dms/gateways file on the server the following message is displayed:
Enter the IP address of the gateway[s] between the client
subnet and server subnet. (For example, 16.69.144.???). :
If an entry for the client's subnet is found in the /var/adm/dms/gateways file on the server the following message is displayed:
The following are the known gateway[s] between the client subnet
and server subnet. If these value[s] are not correct, please
enter the proper address[s]. If these value[s] are correct,
press Return. (For example, 16.69.144.???)
[16.69.144.199]:
Note
The default is ln0, which is appropriate for the DEC 3000 series and other systems that use the Lance Ethernet module. Some systems such as the EB64+ use the Tulip Ethernet module, which is identified as, for example, tu0. Be sure to enter the correct network device identifier for the Ethernet or FDDI interface on the client system.
Enter the type of kernel build area for client1. You may select one of [F]ull, [P]artial, [N]one or [H]elp for more information. [P]:
You have specified the following configuration for client1:Is this correct (y/n) [y]:
ROOT: /clients/client1 SWAP_DEVICE: /dev/rz0b SWAP_TYPE: RZ26 BUILD_TYPE: Partial INTERFACE: ln0 (16.69.244.32) SUBNET_MASK: 255.255.255.0 ROUTE: network: 16.69.224 gateway: 16.69.144.199
If you enter n, the utility returns to the DMU Main Menu and you will have to add your client information again. If you enter y, you are prompted to select the dataless environment to which you want to add the client. The directory /clients/client1 is overwritten if it currently exists.
The existing environment is /var/adm/dms/dms0.alpha.
The following environment will be installed from /var/adm/dms/dms0.alpha:
Description 1 'Digital UNIX 4.0 Operating System (Rev xxx)'
Is that correct? (y/n) [y]:
If there are multiple /var/adm/dms/dmsn.alpha areas, or if more than one dmsn.alpha environment is installed in this DMS server area, a list of the environments into which you can add the new client is displayed. As shown in the following example, each environment may contain different software subsets or may have been customized which may influence the environment you choose.
Select the remote dataless environment:Enter your choice: 2
1) /var/adm/dms/dms0.alpha 'Digital UNIX 4.0 Operating System (Rev xxx)'
2) /var/adm/dms/dms1.alpha 'Digital UNIX 4.0 Operating System (Rev xxx)' 'DEC Pascal for DEC OSF/1 AXP Runtime Support' 'DEC Fortran for OSF/1 AXP Runtime Support' 'DEC Cobol RTL V2.2 for DEC OSF/1 Systems' 'DEC C++ RTL Version 3.0 for DEC OSF/1 SYSTEMS'
The following environment will be installed for the client from /var/adm/dms/dms1.alpha:
Description 'Digital UNIX 4.0 Operating System (Rev xxx)' 'DEC Pascal for DEC OSF/1 AXP Runtime Support' 'DEC Fortran for OSF/1 AXP Runtime Support' 'DEC Cobol RTL V2.2 for DEC OSF/1 Systems' 'DEC C++ RTL Version 3.0 for DEC OSF/1 SYSTEMS'
Is that correct? (y/n) [y]:
Enter the client processor's hardware network
address. For example, 08-00-2b-02-67-e1:
08-00-2b-30-68-96
Refer to the Network Programmer's Guide or Section 6.2 for information about how to obtain a network hardware address. If you do not enter the hardware address in the correct format (for example, too many numbers), the utility displays an error message and repeats the prompt as shown in the following example:
08-2b-30-68-9696 is an invalid Ethernet or FDDI address.Enter the client processor's hardware network address. For example, 08-00-2b-02-67-e1:
Note
The utility does not check the validity of the address you enter; however, the utility does check to make sure the address you enter is in the correct format.
Checking file system space required for client root and var file systems.
There is not enough free space in /clients to create the root and var file systems for client1. client1 has not been added.
The DMU Main Menu is displayed.
Creating the root and var file systems for client1Client client1 has been added.
Notify the client's system administrator when client registration is complete, and inform them that they can now boot the client across the network. See Section 12.2 for basic information about booting a client. Detailed booting information is in the Installation Guide.
After a DMS client is added to the appropriate environment, the client's system administrator can boot the client over the network. When the client starts to boot, the kernel that boots over the network is: /clients/hostname/.vmunix
The following occurs when the client boots:
The network information you entered about the client when the client was added to the environment is sufficient to boot successfully across the LAN.
DMS clients must be able to boot over Ethernet or FDDI LAN. The basic procedure for booting a processor over the network from a Digital UNIX server is to shut down the client system to console mode and then issue a boot command from the client.
Refer to the Installation Guide for information about booting specific processors.
When the client boots, the client system administrator is prompted to enter a superuser password. The superuser password must contain between 6 and 16 characters and should use a combination of upper and lower case letters. Digital also suggests using special characters such as the dollar sign ($), percent sign (%), asterisk (*), and numbers in the password. The password is not displayed on the screen for security reasons. A second prompt asks for the new password again as validation. The screen display is similar to the following:
*** SUPERUSER PASSWORD SPECIFICATION **
Changing password for root.
Enter root password: Retype root password:
System information is displayed while the client system is coming up. When the Common Desktop Environment (CDE) login window or the login prompt appears, enter root as the login name. At the prompt for a password, enter the superuser password that was previously specified.
The DMS client database file is located in /var/adm/dms/clients/dmsdb. An entry in this file is similar to the following:
client1:08-00-2b-30-96-68:/var/adm/dms/dms0.alpha:/clients/client1: rz0b:RZ26:None:ln0:255.255.255.0
In the previous example:
When you remove a client through the REMOVE a client option from the DMU Main Menu, the client's entry in the dmsdb file is erased.
When you delete a software environment, the environment itself and all clients registered to that environment are deleted in a destructive manner. That is, once you confirm your choice, there is no opportunity to undo the deletion.
Caution
Make sure that the clients registered to the environment have been notified and shut down before you delete the environment. Failure to do so will cause a running client to lose its operating system.
To delete a software environment, use the following steps:
*** DMU Main Menu ***
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
Enter your choice:
d
Select the remote dataless environment:
1) /var/adm/dms/dms0.alpha 'Digital UNIX V4.0 Operating System (Rev xxx)'
2) /var/adm/dms/dms1.alpha 'Digital UNIX V4.0 Operating System (Rev xxx)' 'Sort Runtime Library'
3) /var/adm/dms/dms2.alpha 'Digital UNIX V4.0 Operating System (Rev xxx)' 'System V Environment'
The following environment will be deleted from /var/adm/dms/dms0.alpha:
Description 'Digital UNIX 4.0 Operating System (Rev xxx)'
Is that correct? (y/n) [y]:
If you enter n, the utility returns to the DMU Main Menu. If you enter y, the following message displays:
After this deletion, the area /var/adm/dms/dms0.alpha will be empty. The following clients are registered for /var/adm/dms/dms0.alpha: client1 client2 client3This procedure will completely remove /var/adm/dms/dms0.alpha. Do you want to continue? (y/n) [n]:
If you enter n or press the Return key (to accept the default), the utility returns to the DMU Main Menu and does not delete the environment or the clients registered to it. If you enter y, the utility deletes the DMS environment and all the clients registered to that environment and displays the following message:
Do you want to remove the client's root file system [/clients/client1]? (y/n) [n]:
The utility prompts you to answer whether or not you want to remove the root and var file systems for each client registered to the environment. This is your opportunity to save customized data in the root directory. If you enter n, all customized data in root will be lost.
After the deletion is complete, the utility returns to the DMU Main Menu.
The dmu utility lets you modify the network hardware address of a client. Refer to the Network Programmer's Guide or Section 6.2 in this manual for instructions about how to obtain the hardware address of a client.
To modify a client's information perform the following procedure:
*** DMU Main Menu ***Enter your choice: m
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
The following clients are available to modify:Enter the client processor's hostname or press RETURN to quit: client4
client4 client5 client6
If you do not enter a client name and press the Return key, the utility returns to the DMU Main Menu.
Note
The utility does not check the validity of the address you enter; however, the utility does check to make sure the address you enter is in the correct format.
Enter the client processor's hardware network address.
For example, 08-00-2b-02-67-e1 [08-00-2b-30-68-96]:
08-03-3c-01-55-44
Client client4 has been modified.
If you press the Return key instead of entering a new Ethernet or FDDI address, the address will not change. When the modification is complete, the utility returns to the DMU Main Menu.
Caution
If you want to change the client's IP address or the environment to which the client is registered, you must first shut down the client, (by using the shutdown command) and then remove the client from the current environment (by choosing REMOVE a client from the DMU Main Menu). Then, add the client to another environment (by choosing ADD a client from the DMU Main Menu).
You must make sure the client has been shut down (using the shutdown command) before it is removed from an environment. A client will lose its operating system if it is removed while it is up and running. Follow these steps to remove (delete) a client from a DMS environment:
*** DMU Main Menu ***Enter your choice: r
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
You have chosen to remove a client from the remote dataless service.
Enter the client processor's hostname or press RETURN to quit:
client5
If you press the Return key, the utility returns to the DMU Main Menu. If you enter a client name that is not in the DMS client database, /var/adm/dms/clients/dmsdb, the following message is displayed:
There is no entry for client_name in the dmsdb file.
If you enter a valid client name, the following prompt displays:
Remove client5? (y/n) [n]:
client5 was not removed.
Working....Mon Jul 10 15:20:34
The client's registration to the DMS environment along with the following additional items is deleted:
Note
If you remove a client but choose to save the root file system, you cannot reuse that root file system if you subsequently add a client with the same client name.
When client removal is complete, the utility returns to the DMU Main Menu.
Choose the List Registered Clients option on the DMU Main Menu to see a list of the clients registered in all dataless environments:
*** DMU Main Menu ***
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
Enter your choice:
l
The following clients are registered for /var/adm/dms/dms0.alpha:
client1 client2 client3The following clients are registered for /var/adm/dms/dms1.alpha:
client4 client5 client6The following clients are registered for /var/adm/dms/dms2.alpha:
client7 client8 client9
The dmu utility lets you display a list of the current DMS environments:
*** DMU Main Menu ***Enter your choice: s
a) ADD a client c) CONFIGURE software environments d) DELETE software environments i) INSTALL software environments l) LIST registered clients m) MODIFY a client r) REMOVE a client s) SHOW software environments x) EXIT
1) /var/adm/dms/dms0.alpha 'Digital UNIX 4.0 Operating System (Rev xxx)'
2) /var/adm/dms/dms1.alpha 'Digital UNIX 4.0 Operating System (Rev xxx)' 'System V Environment '
3) /var/adm/dms/dms2.alpha 'Digital UNIX 4.0 Operating System (Rev xxx)' 'Sort Runtime Support'
After displaying the list of DMS environments, the utility returns to the DMU Main Menu.
Note
Only the Digital UNIX product name is displayed by the Show command of the /usr/sbin/dmu utility. To determine if a hardware release is installed in a DMS environment, use the setld command. For example, the following command produces a list of the subsets installed into the client root area of /var/adm/dms/dms0.alpha:
# setld -D /var/adm/dms/dms0.alpha/root -i
Refer to setld(8) for more information or enter the following command to display the reference page on your screen (if the Digital UNIX reference page software subsets have been installed on your system):
#
man setld
This section contains information about maintaining the DMU server area.
The du command displays a summary of disk usage for file systems. Use this command to monitor the file growth in each client's root directory. If clients use too much space, performance is adversely affected. Users must then be told to delete all unnecessary files from their file systems. Monitor disk usage periodically depending upon the systems' use. Refer to du(1) for more information about monitoring file system growth.
The df command displays statistics about the amount of free space on a specified file system or on a file system that contains a specified file. Refer to df(1) for more information about monitoring file system growth.
Use the setld utility to determine which software subsets are installed into a particular dmsn.alpha area. For example, the following command produces a list of the subsets installed into the client root area of /var/adm/dms/dms0.alpha:
#
setld -D /var/adm/dms/dms0.alpha/root -i
Refer to setld(8) for more information or enter the following command to display the reference page on your screen (if the Digital UNIX reference page software subsets are installed on your system):
#
man setld
Use the
setld
utility to remove software subsets from a
dmsn.alpha
area. For example, if you installed the Online Reference Pages
subset, OSFMAN400, and now want to remove it, use a command
similar to the following:
#
setld -D /var/adm/dms/dms0.alpha/root -d OSFMAN400
This command removes the subset from /var/adm/dms/dms0.alpha. The Installation Guide contains a list of all software subsets.
Caution
During the installation if setld placed files in root, the product may not be fully removed from the client's root file system. Additionally, you should be careful about removing any subset that might be in use by client systems. For example, if you remove a subset that contains kernel build files, the clients may not be able to build new kernels. If you remove a subset that contains NFS components, the clients may not be able to reboot. It is important to understand exactly what dependencies clients have on a software component before you remove it. You may not be able to reload a subset to resolve client operational problems without first removing all of the clients and then reregistering them.
This section describes how to apply binary patches to the kernel in a DMS environment without deregistering and reregistering all of the client systems or reinstalling the DMS environment.
Binary patches to the Digital UNIX operating system are often issued to address problems in the kernel or layered products.
When a binary patch affects only files in the /usr file system or other file systems that are mounted read-only by the DMS clients, simply copy the files into the shared /usr file system on the server. The usual cautions that apply to changing the /usr file system in a multi-user environment apply to the DMS environment for instance, replacing a shared library has the same potential impact.
When the binary patch changes object modules (or source files) in the /sys area in /usr/sys on a stand-alone system, the situation is more complicated in the DMS environment. This is due to the way the client's /sys area is set up, which differs depending on how the client builds kernels.
The following sections assume that all the client root file systems are NFS mounted from the server.
Ensure that you have the appropriate binary patch for the version of Digital UNIX that is installed in the DMS area. If you install an incorrect version of the patch, you may create a kernel that will not work on the client systems, or you may create a kernel that causes data corruption. To obtain the exact version names, use the following command:
#
grep -h "^NAME=" /usr/var/adm/dms/dms0.alpha/root/usr/.smdb./OSFBASE*
NAME='Digital UNIX Operating System 4.0 ( Rev xxx)' NAME='Digital UNIX Operating System Hardware Update Release'
In this example, the dms0.alpha area contains both the Digital UNIX Operating System Version 4.0 ( Rev xxx) base release and the hardware update release. Repeat the previous step for each area until you find the one which has the correct version of the hardware update release installed.
Follow the instructions in the patch kit to install the patch in the server's DMS area.
To install the patch into the dms0.alpha area in the BINARY directory where most kernel .o object files are located, enter the following command:
#
cd /usr/var/adm/dms/dms0.alpha/root/usr/sys/BINARY
Use the ls command to verify that the object file present in the sys/BINARY directory is the one you want to replace. Make a copy of the file under another name. If you are going to replace the file if_tu.o, copy it to if_tu.o-bak or if_tu.o-old. Later, if there is a problem with the patch, you can restore the original file. After you verify the files to replace and make backup copies, put the replacement files into the directory. You are ready to build a new DATALESS kernel.
To assure that your new DATALESS kernel picks up the patched modules, remove the old DATALESS kernel build area from your server by entering the following commands:
#
cd /usr/var/adm/dms/dms0.alpha/root/usr/sys
#
rm -rf DATALESS
You do not need to keep the old DATALESS directory because its contents will be completely replaced when you run doconfig to build a new kernel. Use the -n flag or doconfig will not create a .vmunix, which is used to boot the client using the bootp protocol. However, removing the directory assures that you will get the correct files for building the new kernel.
The following sections describe how to update the client area based on the client's build type.
If the client's kernel build type is NONE you must copy the DATALESS kernel to the client's root area. To copy the new vmunix and the network-bootable .vmunix to the client's root, enter the following commands:
#
cd $DMSROOT/root
#
ROOT_PATH=/clients/
client_name
#
export ROOT_PATH
#
cp usr/sys/DATALESS/vmunix $ROOT_PATH
#
cp usr/sys/DATALESS/.vmunix $ROOT_PATH
When you reboot the client, the client will use the new generic .vmunix with the binary patch installed.
When a client is configured to do Partial kernel builds, the client receives a copy of the DMS area's root/usr/sys directory with the exception of the /usr/sys/BINARY and /usr/sys/include directories. The client's /sys has a symbolic link to the read-only /usr/sys/BINARY and /usr/sys/include in the server's DMS area.
If the replacement file or files from the patch kit all reside in either the /usr/sys/BINARY or /usr/sys/include directories in the server's DMS area, rebuild the kernel on the client system and reboot.
If the replacement file or files reside in another part of the /usr/sys directory, copy them to the corresponding place in the client's sys directory hierarchy.
Next, the doconfig command must be run on the client. Use the -n flag or doconfig will not create a .vmunix, which is used to boot the client using the bootp protocol.
When a client is configured to do full kernel builds, it receives a full copy of the /root/usr/sys directory hierarchy.
In this case, you must first install all the patch files that you have put in the server's DMS area in the /usr/sys hierarchy into the corresponding places in the client's sys area. For instance, if you installed the module if_tu.o into /usr/sys/BINARY in the server's DMS area, you need to also install it in /clients/ client_name /sys/BINARY.
Because clients that are configured to do full kernel builds may have already modified some kernel objects, be sure to verify that the module you are replacing is the same module you replaced in the DMS area on the server.
Next, run the doconfig command on the client. Be sure to use the -n flag or doconfig will not create a .vmunix, which is used to boot the client via bootp protocol.
Be sure that the client's build area does not contain files that are customized for the client's particular environment.
After you have installed the new kernel in the client's root area, reboot the client system for the kernel changes to take effect.
If the client system cannot reboot, you can usually recover by copying the generic network-bootable .vmunix from the DMS area's root area to the client's private root area.
Doing this should let the client boot. You still need to determine why the new kernel was not bootable.