Well, in this blog, I would be talking about a curious issue I encountered while I was doing a Hyperion EPM install on a Linux box. Well, I was doing a full install including an Oracle database. The user root is the user name or account that has access to all commands and files on the Linux/Unix operating system. However, root user assumes that you act responsibly since you have access to the entire system. And many a times software installers will not allow installs to run in root mode simply as a defensive programming technique.
The below snapshot shows me entering into the root mode on a Linux box.
The next snapshot shows me launching the Hyperion EPM installer as shown below.
The next snapshot shows the components that I have selected for install. I have chosen just an FDMEE to be installed.
Now most of the components install passes successfully, however, ODI install fails, although the FDMEE web app is installed successfully as shown in the below snapshot.
Now, the install log files that are created is shown in the below snapshot.
When you check the installTool log, you will observe that the ODI install is failing because the user root has superuser privileges. And ODI blocks the superuser from running the ODI install.
Now, the standalone ODI install that I had done previously also had the same issue…
Now the best part. If you are installing Hyperion components like Planning or Essbase, the root install will work successfully. However, if you choose FDMEE to be installed, the install will fail because of ODI installer blocking a super user from running the command. So although the root install for Hyperion EPM will work in some cases, there would be times when same steps would fail simply because of a component you selected during the configuration.
(Ideally, you would not want to do an install in the root mode. However, since a root user has unfettered access to the system, many a times doing an install in this mode is tempting since you don’t run into the access permission issues. Always remember that, the root user is for DEFCON-1 situation only or when the system directories need to be manipulated like the case with Oracle database. Installs are way more fun when you run it as a normal user.)
The below snapshot shows me entering into the root mode on a Linux box.
The next snapshot shows me launching the Hyperion EPM installer as shown below.
The next snapshot shows the components that I have selected for install. I have chosen just an FDMEE to be installed.
Now most of the components install passes successfully, however, ODI install fails, although the FDMEE web app is installed successfully as shown in the below snapshot.
Now, the install log files that are created is shown in the below snapshot.
When you check the installTool log, you will observe that the ODI install is failing because the user root has superuser privileges. And ODI blocks the superuser from running the ODI install.
Now, the standalone ODI install that I had done previously also had the same issue…
Now the best part. If you are installing Hyperion components like Planning or Essbase, the root install will work successfully. However, if you choose FDMEE to be installed, the install will fail because of ODI installer blocking a super user from running the command. So although the root install for Hyperion EPM will work in some cases, there would be times when same steps would fail simply because of a component you selected during the configuration.
(Ideally, you would not want to do an install in the root mode. However, since a root user has unfettered access to the system, many a times doing an install in this mode is tempting since you don’t run into the access permission issues. Always remember that, the root user is for DEFCON-1 situation only or when the system directories need to be manipulated like the case with Oracle database. Installs are way more fun when you run it as a normal user.)
No comments:
Post a Comment