Sharing Resources - Why and How

Sharing resources saves space by sharing duplicate files across a Linux network. For example, you might have 30 networked systems all running Linux. The systems are grouped by function, so some of them have directories that are almost identical to the other computers in their group. If you think of these systems as VM users on a zSeries running Linux, you can save space by not sharing directories.

To save space, and to make like systems consistent, specific directories on minidisks can be shared. Sun Update Connection – Enterprise automatically locks these directories, so that the owner of the minidisk has full access, but sharing hosts have read-only access. Automatically fulfilling this requirement saves the VM operator time and makes sure the system is secure and consistent.

Another Shared Resources requirement is that the sharing hosts have specific mount points to the shared minidisk. This is also fulfilled automatically by Sun Update Connection – Enterprise.

Mount Points for Shared Directories

Sun Update Connection – Enterprise manages software, so efficient sharing in an Sun Update Connection – Enterprise system concentrates on software-relevant directories. Sun Update Connection – Enterprise shared resources support is relevant to Linux operating system directories, not user-defined directories.

The most important shared directories are /usr and /opt.

The /usr directory contains system libraries, administrative commands and files, and the main files for installed applications. When you install an application, its main parts go in the /usr directory. Other directories hold the configuration files and data, the type of things that you want to sometimes change. Sharing the /usr directory means that multiple VM users (master host and sharing hosts) can use the same applications, although the largest part of the package is be installed only once (on the master host).

The directories that you want to share must be mounted in /proc/mounts of both the master host and the sharing hosts.

Master Host and Sharing Host Synchronization

When you install an application on a Linux image, some files are installed in directories other than /usr. Therefore, when you use Sun Update Connection – Enterprise to install an application on a master host, the same job must run on all of the sharing hosts of the master host. The application is installed only once, but every sharing host requires the dependent components installed in other directories.

Failing to maintain duplicate installation procedures between a master host and its sharing hosts causes synchronization errors. Such errors disable management on the unsynchronized sharing hosts. Sharing hosts that do not perform the same installation job as its master host cannot function as a managed host of Sun Update Connection – Enterprise.

To automatically maintain synchronization, Sun Update Connection – Enterpriselimits jobs that include sharing hosts..

The following synchronization limits apply:

• You cannot send a job to only one or some of the sharing hosts of one master host; you must send it to the master host only. Sun Update Connection – Enterprise ensures that the sharing hosts also receive the job.

• RPM jobs must be sent to a master host that is online. If the master host is down, the job fails.

• Every managed host must have either zero or one master host. It must either be a master host or have only one master.

To Create a Master Host

1. Define a VM user with read or write access to some minidisks.

2. At the end of the profile exec a file, type the line: ipl <dev #>

3. Upload Linux (with the DDR utility) onto <dev #>.

4. Start the new VM user from any 3270 emulation.

5. Change the TCP/IP of this new Linux image with the ifconfig command.

6. Fix the routing table and then connect with telnet to the new VM user.

7. Change the network configuration with YAST (5-6) to be permanent.

8. Restart Linux.

9. Copy the agent.tgz file to the new VM user Linux operating system.

10. Untar the file and type ./Install to start the agent ezInstaller.

11. After the agent is installed, view the agent configuration file.

    vi /opt/local/uce/agent/bin/uce.rc

12. Find the mf_shared_path parameter and check the value for this parameter. The value should be /usr or /opt, according to the directory that you want this sharing host to access from its master.

    If the value is incorrect, copy the entire line of this parameter to the .uce.rc file and edit the value to be the correct directory. When the Sun Update Connection – Enterprise agent is installed on this VM user, you have a master host.

To Create a Sharing Host

1. Define a VM user that, in addition to its own minidisks, has links to the minidisks of another VM user, with read-only access.

   The VM user that controls the linked resources is the master host of this sharing host.

2. At the end of the profile exec a file, type the line: ipl <dev #>

3. Upload Linux (with the DDR utility) onto <dev #>.

4. Start the new VM user from any 3270 emulation.

5. Edit the /boot/parm file: add (ro) near dev # items that are owned by the master host. Example: dasd=xxxx-yyyy, 202 (ro), zzz

6. Edit the /etc/fstab file: specify read-only mount points for the shared disks; make sure that the last two parameters on the line are “0 0”.

7. Do a silo/zilo.

8. Change the TCP/IP of this new Linux image with the ifconfig command.

9. Fix the routing table and then connect with telnet to the new VM user.

10. Change the network configuration with YAST (9-10) to be permanent.

11. Restart Linux.

12. Copy the agent.tgz file to the new VM user Linux operating system.

13. Untar the file and type ./Install to start the agent ezInstaller.

14. After the agent is installed, view the agent configuration file.

    vi /opt/local/uce/agent/bin/uce.rc

15. Find the mf_shared_path parameter and check the value for this parameter. The value should be /usr or /opt, according to the directory that you want this sharing host to access from its master.

    If the value is incorrect, copy the entire line of this parameter to the .director.rc file and edit the value to be the correct directory. When the installed agent starts, it discovers that it is running on a shared disk environment and registers its VM user as a sharing host on the system dependency server. When an agent starts, a master host writes its master signature in /<shared_path>/.aduva_master

    A sharing host attempts to write to the same path. It finds that it does not have write permissions, reads the .aduva_master file and discovers both that it is a sharing host and who is its master.

To Unregister a Sharing Host From the System Dependency Server

1. Take the sharing host offline.

2. In the Hosts window, select the host from the All Hosts Group.

3. Click Delete.

4. In the confirmation dialog box that opens, click Delete.

To Unregister a Master Host From the System Dependency Server

Before You Begin

Ensure that the master host and all of its sharing hosts are offline.

1. In the All Hosts Group, select the Master Host, then click Delete.

2. In the confirmation dialog box that opens, click Delete.

3. Select the icon for the empty Master Group, then click Delete.