Non-Root Install - Anyone doing this?

[jsquizz]

Greetings,

We are looking at the possibility of doing a non-root implementation for both CMOD and DB2. I have successfully done this in my lab environment - and I haven't seen any issues at all.

I am just wondering- is anyone else doing this or something similar? And has anyone seen any drawbacks to doing it this way? I cannot think of any.

Also- I know how IBM likes to have undocumented features. Is it possible to change the directory for a non-root install? I know this is probably one limitation, and my linux team isn't happy about having to increase /home.

Thanks!

[Justin Derrick]

This is very common now.  The problem with root installs is that if a way is found to compromise Content Manager OnDemand (i.e. remote code execution) then the entire server is compromised.  With CMOD (and arssockd) under a non-root account (archive or odadmin) the amount of damage is reduced, but not necessarily eliminated.

-JD.

[jsquizz]

This is very common now.  The problem with root installs is that if a way is found to compromise Content Manager OnDemand (i.e. remote code execution) then the entire server is compromised.  With CMOD (and arssockd) under a non-root account (archive or odadmin) the amount of damage is reduced, but not necessarily eliminated.

-JD.

Yeah, that's our logic as well. It's a nice feature.

We are just getting pushback from our system admins about installing software in /home/instance. That's why I was wondering if there's a way to "backdoor" it to /opt or some other file system. Same question exists for DB2, which I also installed as non-root.

[Justin Derrick]

Oh, you can still install it in /opt (you need root) but you configure it to run in 'userspace' by changing the owner of the installation to the user account.  The instructions in the IBM CMOD Installation Guide will walk you through it.

[jsquizz]

Oh, you can still install it in /opt (you need root) but you configure it to run in 'userspace' by changing the owner of the installation to the user account.  The instructions in the IBM CMOD Installation Guide will walk you through it.

Nice! Thank you, I will check that out!

I tried tricking it with a response file. That does not work 

[Alessandro Perucchi]

I have done non root implementation of CMOD for the last 15 years, since it was possible to do it. And without any problems.
I would say that now in Switzerland no CMOD is using root account anymore, or at least 99.99% of all customers :-D I don't know all of them!

Now the installation with non-root, as you have found out, you cannot change the installation path. It will ALWAYS be $HOME/ibm/ondemand/Vxxxx or $HOME/IBM/ondemand/Vxxx on AIX.
Of course you can trick with the silent installation file, BUT all upgrades, etc... won't work. This is really sad and InstallShield is not really flexible in that area... I would like that IBM ditch that install software, but one can dream!

Nevertheless, what I also found is that if you install in a non standard installation path (I mean the official /opt/ibm/ondemand/Vxxx or /opt/IBM/ondemand/Vxxx), and it doesn't matter if you install with root or non-root ( $HOME/ibm/ondemand/Vxxx or $HOME/IBM/ondemand/Vxxx is NOT standard installation path for OnDemand strangely enough...), then you need to use the variables:

ARS_INSTALL_SERVER_Vxxx_DIR
ARS_INSTALL_ODWEK_Vxxx_DIR

And be careful that ARS_INSTALL_SERVER_Vxxx_DIR = ARS_INSTALL_ODWEK_Vxxx_DIR.

where xxx = 101 for OD V10.1
xxx = 95 for OD V9.5
xxx = 90 for OD V9.0
xxx = 85 for OD V8.5

Otherwise, I have found that some actions like all tools based on ODWEK (ICN) and some internal tools of CMOD, are lost in space... because for some reasons they still look at the /opt/... standard path...

Regards,
Alessandro

[jsquizz]

I have done non root implementation of CMOD for the last 15 years, since it was possible to do it. And without any problems.
I would say that now in Switzerland no CMOD is using root account anymore, or at least 99.99% of all customers :-D I don't know all of them!

Now the installation with non-root, as you have found out, you cannot change the installation path. It will ALWAYS be $HOME/ibm/ondemand/Vxxxx or $HOME/IBM/ondemand/Vxxx on AIX.
Of course you can trick with the silent installation file, BUT all upgrades, etc... won't work. This is really sad and InstallShield is not really flexible in that area... I would like that IBM ditch that install software, but one can dream!

Nevertheless, what I also found is that if you install in a non standard installation path (I mean the official /opt/ibm/ondemand/Vxxx or /opt/IBM/ondemand/Vxxx), and it doesn't matter if you install with root or non-root ( $HOME/ibm/ondemand/Vxxx or $HOME/IBM/ondemand/Vxxx is NOT standard installation path for OnDemand strangely enough...), then you need to use the variables:

ARS_INSTALL_SERVER_Vxxx_DIR
ARS_INSTALL_ODWEK_Vxxx_DIR

And be careful that ARS_INSTALL_SERVER_Vxxx_DIR = ARS_INSTALL_ODWEK_Vxxx_DIR.

where xxx = 101 for OD V10.1
xxx = 95 for OD V9.5
xxx = 90 for OD V9.0
xxx = 85 for OD V8.5

Otherwise, I have found that some actions like all tools based on ODWEK (ICN) and some internal tools of CMOD, are lost in space... because for some reasons they still look at the /opt/... standard path...

Regards,
Alessandro

We are analyzing everything from a security standpoint. And just getting much push-back about installing a binary in /home/archive(or whatever instance name

It's good to note that it looks in /opt, thank you for that. We were looking at doing it on a different mount such as /prodInstall/ibm/ondemand/.....

[Alessandro Perucchi]

I have done non root implementation of CMOD for the last 15 years, since it was possible to do it. And without any problems.
I would say that now in Switzerland no CMOD is using root account anymore, or at least 99.99% of all customers :-D I don't know all of them!

Now the installation with non-root, as you have found out, you cannot change the installation path. It will ALWAYS be $HOME/ibm/ondemand/Vxxxx or $HOME/IBM/ondemand/Vxxx on AIX.
Of course you can trick with the silent installation file, BUT all upgrades, etc... won't work. This is really sad and InstallShield is not really flexible in that area... I would like that IBM ditch that install software, but one can dream!

Nevertheless, what I also found is that if you install in a non standard installation path (I mean the official /opt/ibm/ondemand/Vxxx or /opt/IBM/ondemand/Vxxx), and it doesn't matter if you install with root or non-root ( $HOME/ibm/ondemand/Vxxx or $HOME/IBM/ondemand/Vxxx is NOT standard installation path for OnDemand strangely enough...), then you need to use the variables:

ARS_INSTALL_SERVER_Vxxx_DIR
ARS_INSTALL_ODWEK_Vxxx_DIR

And be careful that ARS_INSTALL_SERVER_Vxxx_DIR = ARS_INSTALL_ODWEK_Vxxx_DIR.

where xxx = 101 for OD V10.1
xxx = 95 for OD V9.5
xxx = 90 for OD V9.0
xxx = 85 for OD V8.5

Otherwise, I have found that some actions like all tools based on ODWEK (ICN) and some internal tools of CMOD, are lost in space... because for some reasons they still look at the /opt/... standard path...

Regards,
Alessandro

We are analyzing everything from a security standpoint. And just getting much push-back about installing a binary in /home/archive(or whatever instance name

It's good to note that it looks in /opt, thank you for that. We were looking at doing it on a different mount such as /prodInstall/ibm/ondemand/.....

Well the $HOME is not necessarly /home/xxx but the home directory of your installation, so it could be /prodInstall with the user "prodinstall" (for example) which has his home directory as /prodInstall
then you can give other users the access to it, like the user "cmod". Set the correct variables, and DO NOT FORGET the permissions (https://www.ibm.com/support/knowledgecenter/en/SSEPCD_10.1.0/com.ibm.ondemand.installmp.doc/accountslin.htm) and that would be :
- $ODInstallDir/bin/arslog
- $ODInstallDir/bin/arsprt
- previously also $ODInstallDir/bin/arsrdprt
- don't forget $ODInstallDir/config/ars.ini

So that the other user can use your prodinstall installation :-D It is basically like the CMOD Documentation where you use root to install the product, and then use a non-root user to run your instance.
but here you install with user X and use a none-root, none-X user to run your instance!

Just my 0.0002$ !