non-root install

[denzilsyb]

Hallo all

Im getting grey hairs trying the above, and just need a few things answered..

1) Does anyone have a succesfull non-root installation on solaris 2.9

1.1) if yes, what is the trick. We seem to go by the book, but no luck. The installation fails when attempting to create the projects (of which dsadm:dstage is the owner of the directories)

We did think that the project names were too long, but it does not seem to be the problem (DefaultProject; ContributionDev and ContributionProd). As far as I know, 16 chars is the limit for project names.

2) What does the root install physically do to the OS files? I know /etc/services is edited and the startup daemon is accessed (i think rc2) but what more?

The issue here is that the client is a financial company and root access is a big no-no, even if it is only for 30 minutes. For us to attempt a root install, I need to report back on exactly why root is required. We could be installing transfers of millions to my account for all they know

[Amos.Rosmarin]

Hi,

Two weeks ago I enjoyed the installation of PX7.5 on Sun 2.9

Luckily I did it with root but even though it was not easy.

I advise you to add -x to the first line of the install.sh script (/bin/sh -x)

This will cause all commands and message to be printed to screen.
So you could see the execution paln.

It helped me alot

Is it a clean install or an upgrade ??

HTH
Amos

[denzilsyb]

hello Amos

just finished it. man, i dont recommend it. The only problem I have now is to know why the uvrpcd process needs to run as root?

yes, all subsequent connections are dsadm processes, but dsadm cannot start the server, but can stop the server.

[Amos.Rosmarin]

If you can only stop the service then you can report that you have 50% functionality :D

[chulett]

There have been a couple of other posts on the topic of a non-root install and both were discussing problems when doing so on Solaris, from what I recall. Here is one example. The consensus seemed to be that, in spite of the fact that you can do one now, you should stick with a root install.

[denzilsyb]

Thanks dude

It seems almost unfair to document something that can be done that shouldn't be done. Over here we have 2nd level login and passwords that also result in a headache or two.

so..

dsadm types uv -admin -start and the prompt comes up for the 2nd level login/password. dsadm types it in and then DS returns to the cmd line. the DS service are not started. I assume then that the su command within uv returns to the cmd line not being able to handle the input from the user.

If root does the same, the DS service is started. (no 2nd level required)

getting back to the install...

After the installation as a non-root user, there are 2 scripts to execute. These we execute as root and the uv file is now owned by root, with a few others with setuid permissions on them. I think they should rather be owned by the user that installed datastage.

I did read in the post you pointed me to that root starts the service from rc2.d, which is understandable - the environment variables are all there (ok - after we put them there; actually in rc3.d; for some reason rc2.d is not inline with the implementation policy here). So... why not let dsadm, the install user start the script from $DSHOME/bin?

On a point though - would it make sense for DS to manage its own users and groups? There is already a repository for metadata, why not add to that a little user database?

[ray.wurlod]

On a point though - would it make sense for DS to manage its own users and groups?

Whatever you decide must work on Windows platforms too!
On Windows platforms user and group management is quite different, for example domain\user, machine\user and user may or may not all exist.

FYI, project names must conform the the SQL 92 rules for schema names:

• begin with an alphabetic character
  contain only alphabetic, numeric and underscore characters
  not end with an underscore character
  contain not more than 18 characters