OpenSpirit enable cross-vendor, cross platform... Integration of Data and Applications
About Us Products Support Services Clients News Contact Us
End-User FAQ: Version 2.5.0 End-User FAQ Menu

Admin/Install >> Configuration

I made a change to my datastore but I'm still getting the same error when I try to start my dataservers!
We just reconfigured our network and applications are hanging. Why?
My company does not configure Solaris to run the rexecd deamon. What limitations does this impose on our OpenSpirit installation?
My company does not allow the rexecd daemon. How do I implement SSH?
**This is available for v2.9.0 and higher only!
I cannot create an SDE scanset in the OpenSpirit ScanUtility because the "New" button is grayed out. How do I configure my SDE account in order to create OpenSpirit SDE scansets?

I made a change to my datastore but I'm still getting the same error when I try to start my dataservers?

If you are still getting the same error that you had and one of your dataservers (Geoframe or OpenWorks for example) won't start, then you most likely didn't re-run the $OSP_HOME/bin/registerservers.sh script.

If you make any changes to the configuration after your initial installation you will need to run the $OSP_HOME/bin/registerservers.sh script again.

Back to Top ...

We just reconfigured our network and the applications are hanging. Why?

The COP database must be cleared of the old IORs. The Units and Coordinates servers persist objects in the CORBA Object Persistence (COP) part of the Auxiliary Data Store (ADS). These persisted objects contain the IORs of related objects, which hold the IP address of the machine on which the server is expected to be running (or the Object Activation Daemon that knows how to run the process to reconstitute the object). If that IP address no longer points to the right machine, objects will hang as they wait for the machine to respond.

To fix this, first remove all persisted CORBA objects from the database. You can do this using the $OSP_HOME/bin/cops.sh tool. Now stop all of the shared servers, clear the database by runnings cops.sh, then restart all of the shared servers.

Back to Top ...

My company does not configure Solaris to run the rexecd daemon. What limitations does this impose on our OpenSpirit installation?

The rexecd daemon enables a network protocol to remotely executie programs with authentication that is based on a userid and password. OpenSpirit uses this protocol for two purposes: starting the user server and data servers on another host; and authenticating your OpenSpirit user identity when registering new users or when adding a new alias to an existing user.

Limitations imposed by not running rexecd are:

  • Users will not be able to register themselves via the OpenSpirit User Registration dialog, or add new aliases to an existing OpenSpirit user without access to a host that is running rexecd and access to the OpenSpirit installation file system. The only workaround is for your OpenSpirit administrator to run the OpenSpirit User Manager tool ($OSP_HOME/bin/userMgr.sh). This will register your Unix account as a new OpenSpirit user.
  • When the OpenSpirit Launcher is started, it searches for an OpenSpirit user server running somewhere on your network under a userid that your OpenSpirit account has been aliased to. The Start OpenSpirit User Server dialog is displayed if the Launcher cannot find a running user server. Environments that do not run rexecd won't be able to choose the Remote Unix Host option. You must choose the Local Host option, or log into the remote host and manually start your user server by using the command $OSP_HOME/bin/runUserServer.sh start.
  • The OpenSpirit framework will only be able to run data servers on the same host that your user server is running on. You will not be able to specify a data server host (in the Server Activation tab of the OpenSpirit Launch) if the host is not running the rexecd daemon. You must go with the default of running data servers on the same host as the user server.

Back to Top ...

My company does not allow the rexecd daemon. How do I implement SSH?
**This is available for v2.9.0 and higher only!

In OpenSpirit 2.9.0 and later, another option is to implement SSH. SSH must first be available on the OpenSpirit server. After you verify that SSH is available in your environment you can enable SSH security for the OpenSpirit Master installation using the following procedure:

  1. Stop the OpenSpirit shared services
  2. Add the following line to the master installation's $OSP_MASTER_HOME/classes/OpenSpirit.properties file:

    openspirit.remoteStartMethod=ssh

  3. Restart the OpenSpirit shared services.
**If you are using OpenSpirit v3.0 or higher!
  1. Complete steps 1 & 2 from above, then, edit the $OSP_HOME/external/OpenSpirit/plugins/process/OspPlugin.xml file. Currently that file contains two sections (rexec, and SSH). The first is for rexec and it is the default. The second setction is for SSH and it is commented out with the XML start/end comments <!-- and -->. If you switch to SSH you will need to comment out the first section and uncomment out the second section.
  2. Restart the OpenSpirit Shared Services.

Back to Top ...

I cannot create an SDE scanset in the OpenSpirit ScanUtility because the "New" button is grayed out. How do I configure my SDE account in order to create OpenSpirit SDE scansets?

The SDE account you use to connect to the SDE data base from the OpenSpirit ScanUtility must be an SDE Oracle account, and it must have privileges in the SDE SCAN_SET_INFO table.

First, you need an SDE account set up as per ESRI documentation, “ArcSDE Configuration and Tuning Guide for Oracle”. Your user must be able to create SDE layers in your SDE instance.

Second, your SDE account needs permissions on the SCAN_SET_INFO table. OpenSpirit places one table, SCAN_SET_INFO, in the SDE administrator's schema. This table is created the first time the Scan Utility is run and contains a central catalog of scan sets. Each SDE user that will create, and manage OpenSpirit SDE scansets must have DELETE, INSERT, SELECT, and UPDATE privileges on the SCAN_SET_INFO table. Your SDE, or database administrator will have to grant you this access before your SDE account can create OpenSpirit scansets with the ScanUtility.

When you have permissions in the SCAN_SET_INFO table, the buttons will not be grayed out. More information on using and configuring the OpenSpirit ScanUtility can be found in the OpenSpirit User's Guide, Chapter 2, Using the Scan Utility, Running the Scan Utility in SDE Mode. The OpenSpirit User's guide can be downloaded from http://www.openspirit.com/documentation.html .

Back to Top ...

Site Map      Legal      Privacy
 
OpenSpirit Home