LMS: wrong environment variables set by installation script ?

[Martin Ermel]

is this behaviour correct or is this a bug?:

LMS 2.6 on solaris

(but I think it is the same with LMS 2.5.1 and below)

if the LMS installation is not done in the default location, a link is created as /opt/CSCOpx that points to the customer choosen install-dir;

thats ok, but when the env vars are written to the package CSCOmd some of them uses /opt/CSCOpx and others use the custom location instead.

for example the installation location is /opt/CSCOpx-xxx (instead of the default /opt/CSCOpx), then the following vars uses the custom location

JAVA_HOME='/opt/CSCOpx-xxx/lib/jre'

PX_CLASSDIR='/opt/CSCOpx-xxx/www/classpath'

PX_SCLASSDIR='/opt/CSCOpx-xxx/lib/classpath'

CLASSPATH='/opt/CSCOpx-xxx/lib/classpath:/opt/CSCOpx-xxx/www/classpath:/opt/CSCOpx/campus/lib/classpath:/opt/CSCOpx/campus/www/classpath'

LD_LIBRARY_PATH='/opt/CSCOpx-xxx/objects/db/lib:/opt/CSCOpx-xxx/lib:/opt/CSCOpx/MDC/lib:/opt/CSCOpx/campus/lib:/opt/CSCOpx/campus/lib'

in some circumstances this prevents the databases from being started, whereas apache and tomcat can be started (Web-login is ok);

I think this must be changed, so that only /opt/CSCOpx is used for env vars - or is there a good reason to do it like this?

MArtin

Edit:

CSCOdb also uses the customer path instead of /opt/CSCOpx for

LD_LIBRARY_PATH

[Joe Clarke]

This is typically the way it works with custom installation directories. However, the problem with the databases not starting should have been addressed in recent versions of LMS. The big problem was that dmgtd was not properly shutting down previous instances of the database engine. Under what circumstances are the databases not being started?

[Martin Ermel]

These circumstances are as follows (both installations only with CM and RME, no DFM, no IPM)

1 server with productive LMS installation (prod-LMS), another 1 with test installation (test-LMS); there is a disc-array with Veritas VxM;

prod-LMS has mounted a Vx-volume as /opt/CSCOpx-prod; LMS installation location was /opt/CSCOpx-prod; /var/adm/CSCOpx was moved to /opt/CSCOpx-prod/var/adm/CSCOpx and a link was generated in /var/adm/CSCOpx that points to the new location;

test-LMS has mounted a Vx-volume as /opt/CSCOpx-test; LMS installation location was /opt/CSCOpx-test; /var/adm/CSCOpx was moved to /opt/CSCOpx-test/var/adm/CSCOpx and a link was generated in /var/adm/CSCOpx that points to the new location;

failover: ( theory ;-) )

so if the productive server fails,its volume will be unmounted and released; test-LMS will shutdown, test volume is released, IP address and hostname are adopted from prod-LMS, /opt/CSCOpx-prod is mounted and productive LMS can be started without a problem....

...

but now there are the env vars which are derived from the CSCO packages....and they are locally on the server in this configuration, and some of the env vars have /opt/CSCOpx in its path and other do have the install dir (e.g /opt/CSCOpx-prod)

Ok, it is typically for custom installations but I think it is not consequent. Is there a reason not to use /opt/CSCOpx in all var paths?

and by the fact that LMS itself uses /opt/CSCOpx as a base and links it to the custom location rather then only use the custom dir...

...And then there is the problem with patch installation; as you said in a former thread, linking of /var/adm/CSCOpx is not supported. For failover szenarios it would be so much easier if it would be supported;- I am not sure, but I think there are a few (?) 4 lines in the install procedure of updates, that manipulates /var/adm/CSCOpx without testing ( for link and corrrect permissons or ownership) and thus destroy the link ... ( but why mourn it is a fact, I think...)

I changed the env vars on both servers- now the dbs come up, but I have another issue that RMEDbMonitor cannot get the pid of rmeng (and I assume it is the same with the other dbmonitors..)

[Joe Clarke]

This configuration is highly dangerous and completely unsupported. You cannot relocate the /var directories under NMSROOT on Solaris. Symlinks aside, things will be broken. If you don't like /var, create a new file system, but do not put this tree under NMSROOT.

The reason /opt/CSCOpx is not used everywhere is due to the fact that paths are resolved in different ways. Some use the realpath while others use the symbolic location. Given a straight custom installation without symbolic linking of /var, you should be okay here.

I would first correct the /var problem, then if your database issue persists, there may be a problem with dmgtd communication. The output of pdshow may help.

[Martin Ermel]

I know that this kind of installation is really not supported - and "dangerous" (in terms of availability) is a pretty description for this - but I inherited it and now I am trying to deal with.

I am on a good way to persuade the owner to change this mechanism ( especially with your last post) but as usual there are a few people involved having all own opinions;

I' ll try to correct the /var problem, check if it works then and will try to get a new fs on the volume to move it there...

[Martin Ermel]

"Given a straight custom installation without symbolic linking of /var, you should be okay here. "

Do I understand you right, that a straight custom installation on both systems should work? Even if I use the GUI afterwards, and change all paths that point to somewhere in /var/adm/CSCOpx, I would assume it would not work, because there are still some refs that points to specific files in /var (e.g. Job Details) which in case of a failure of LMS-prod gets lost because they are local to the server. - i.e. config files could be stored on any filesystem (e.g. disc-array) but storage location for job info files can not be changed;

so if LMS-test takes the role of LMS-prod it will also do some jobs, which on the other hand will store the jobdetails in the local /var of LMS-test;

the only thing I see in this case is to create a symlink for /var/adm/CSCOx that points to any fs on the disc-array (beside NMSROOT) - or do I miss something?

[Joe Clarke]

You are correct that not everything can be moved out of /var. Job information and logs are two of the big items. Configurations and software images can be moved anywhere.

You cannot share file space between two LMS servers (if that is what you are alluding to). There is no way to cluster LMS like that. If LMS-test will be "promoted" to LMS-prod, it will have a completely different set of jobs, software images, configs, etc. While these may be similar to those that are found on LMS-prod, they will not and cannot be identical since you cannot point LMS-test and LMS-prod to the same config archive, software repository, job directory, etc.

Of course, if I misunderstood your question, please clarify.