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.
Define a VM user with read or write access to some minidisks.
At the end of the profile exec a file, type the line: ipl <dev #>
Upload Linux (with the DDR utility) onto <dev #>.
Start the new VM user from any 3270 emulation.
Change the TCP/IP of this new Linux image with the ifconfig command.
Fix the routing table and then connect with telnet to the new VM user.
Change the network configuration with YAST (5-6) to be permanent.
Restart Linux.
Copy the agent.tgz file to the new VM user Linux operating system.
Untar the file and type ./Install to start the agent ezInstaller.
After the agent is installed, view the agent configuration file.
vi /opt/local/uce/agent/bin/uce.rc
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.
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.
At the end of the profile exec a file, type the line: ipl <dev #>
Upload Linux (with the DDR utility) onto <dev #>.
Start the new VM user from any 3270 emulation.
Edit the /boot/parm file: add (ro) near dev # items that are owned by the master host. Example: dasd=xxxx-yyyy, 202 (ro), zzz
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”.
Do a silo/zilo.
Change the TCP/IP of this new Linux image with the ifconfig command.
Fix the routing table and then connect with telnet to the new VM user.
Change the network configuration with YAST (9-10) to be permanent.
Restart Linux.
Copy the agent.tgz file to the new VM user Linux operating system.
Untar the file and type ./Install to start the agent ezInstaller.
After the agent is installed, view the agent configuration file.
vi /opt/local/uce/agent/bin/uce.rc
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.
Take the sharing host offline.
In the Hosts window, select the host from the All Hosts Group.
Click Delete.
In the confirmation dialog box that opens, click Delete.
Ensure that the master host and all of its sharing hosts are offline.