Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Automating OpenView GUI start to support web clients.

Status
Not open for further replies.
Aug 8, 2002
65
US
OK, I'm fairly new to OpenView so go easy on me. I have three users who want to use the web client mostly but they still want to be able to use the full UNIX client if they need to make changes, etc. Each one also wants their own map to tweak. OV runs on Solaris 8 (sunfire 280R, headless). I have already created their maps but I think it'd be cool to automatically start GUI sessions in the background with read only copies of their map if the server is restarted so they can use web access any time they want.

Something like:
%ovw -ro -map mapname &

but send it to a bogus display like a VNC session. This way they can still open writeable copies of their maps if need be. Hmmm, maybe I'm asking a Solaris question here but I figured maybe someone here may have addressed this. Of course this would all be written to be deployed in the appropriate RC script of the machine.

TIA

Brian
 
I encountered something similar to this. Our network operations team wanted to use the network presenter instead of the actual map on my Sun server. Also, since I didn't necessarily trust VNC's security but still wanted to give root ownership of the ovw processes, I decided to set up something to automatically start up the maps with "ro" permissions.

What I ended up doing was creating new lrf files, one for stopping and starting vnc and another to do the same for ovw. Not only did this allow me to specify the order of execution and vnc's and the ovw maps' dependencies, it also allowed me to let an init script start everything up using a simple ovstart. The vnc.lrf and ovw.lrf files themselves referenced some custom scripts that have distinct actions for 'start' and 'stop'.

One last thing to consider, a 'ro' map will not reflect topology or configuration changes unless it is restarted. A simple solution is to have your ovw startup script open the 'rw' versions, give them time to fully synchronize, stop them, and finally start up the 'ro' maps.

Matt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top