This is the fourth in a series of posts regarding installing BI Apps 11.1.1.10.2 on Oracle Linux 7.2. For your reference, here is a list of URLs for each of the posts that make up this series:
OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - Oracle JDK OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - WebLogic OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - OBIEE 11.1.1.9 RCU OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - OBIEE 11.1.1.9 OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - ODI 11.1.1.9 OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - OPatch OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - OBIA 11.1.1.10.2 RCU OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Installation - OBIA 11.1.1.10.2 OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Configuration - OBIEE OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Configuration - OBIA OBIA 11.1.1.10.2 installation on Oracle Linux 7.2 - Finalizing / Wrap-up
In this post, I will be discussing how to install the Oracle Java Development Kit (JDK) version 1.7.0_80.
General Assumptions and Conventions Used
I will assume that readers of this blog have read the three prior blog entries in this series before continuing. Specifically, this blog entry will assume that the Oracle JDK version 1.7.0_80 has been downloaded and placed in the /u01/sw/jdk directory structure that was discussed in the previous blog entry.
Installing Java
Approach
While there are many approaches one can take to install Java into an Oracle Linux 7.2 system, the approach that I recommend taking is to install it into a directory that's owned by the obia11g user. As a result, we will be installing it into /u01/app/obia11g/java/jdk. I recommend taking this approach for several reasons:
Java will not be tied to the operating system. We want to install a very specific version of Java. Your Linux System Administrator may wish to use a different version, or there may be other applications that will coexist on your server which in turn require a different version of Java. Installing Java into its own directory that will be owned by the obia11g user will avoid these types of conflicts.
Java will be installed in a directory owned by the obia11g user and will therefore be "dedicated" to the purpose of installing and running the OBIA software. This helps with organization - it will be very clear what Java version is being used by the obia11g user. It also ensures that the obia11g user will have write access to the Java files, which is something we will need later on.
Java will be installed in a separate volume to the default operating system volumes. This is useful in the event of resolving dependencies if/when the underlying operating system needs to be rebuilt/reinstalled/upgraded. By installing Java into its own directory (which as I mentioned will be owned by the obia11g user), the operating system could be rebuilt and the /u01 volume re-attached without too much additional drama such as various OBIA elements not starting up correctly because the java version installed is different when the OS is changed.
Using symbolic links
Although I very much like using symbolic links, and I do recommend ultimately using a symbolic link with Java after all of the OBIA software has been installed, I have found that utilizing a symbolic link for Java is not the best course of action during the OBIA installation. This is because the installation will derive the ac
tual path from the symbolic link, and this fully resolved path will in turn will get fed into all of the WebLogic startup files and make things much more difficult to work with if an upgrade of Java is desired at some point in the future. More specifically, the derived path will be what gets stored in the configuration/startup script files.
So, what I recommend is to install Java into a generic directory that is absent of version names. For example, /u01/app/obia11g/java/jdk as opposed to /u01/app/obia11g/java/jdk1.7.0_80 (or something like that). Then, when the installation is complete we can come back and replace this generic directory with a symbolic link in order to make things more manageable.
Unarchiving the JDK
Issue the following command to unzip the zip file (note: as I mentioned in a previous blog entry, I got this zip file from eDelivery, however you can get it from other locations. If you do, your command may be slightly different):
$ unzip -q p20418657_17080_Linux-x86-64.zip -d /u01/app/obia11g/java
The zip file contains several files. The one we're interested in is the one containing the JDK. As a result, next we'll change into the /u01/app/obia11g/java directory, untar the JDK file into its own subdirectory of /u01/app/obia11g/java, and then remove all unnecessary files
$ cd /u01/app/obia11g/java
$ tar zxf jdk-7u80-linux-x64.tar.gz
$ rm *
After untarring the archive, you'll notice that it created a subdirectory called jdk1.7.0_80. If you leave it like this and continue on with the OBIA installation, it will work, but updating this version of Java to something newer in the future will become much more complex. What I recommend doing instead is renaming this directory to the generic "jdk".
$ mv jdk1.7.0_80/ jdk
When completed, the directory structure of /u01/app/obia11g/java should look like the following:
Adding variables to .bashrc
Now that the JDK has been installed into /u01, we need to alter our .bashrc file so that certain variables are set. As a result, please open the obia11g user's .bashrc file (~/.bashrc) and add the following lines above where the PATH variable is set:
JAVA_HOME=/u01/app/obia11g/java/jdk
export JAVA_HOME
Then, alter the existing PATH setting to be the following:
PATH=$JAVA_HOME/bin:$PATH:$HOME/.local/bin:$HOME/bin export PATH
Handling the tmp directory
The OBIA installation will make heavy use of your tmp directory. More specifically, it will require that certain files that will be placed in the /tmp directory be executable. By default, the tmp directory is /tmp, however some companies choose to secure the /tmp directory from executing anything (i.e. mounting as noexec, etc.). This is why we created a separate tmp directory located at /u01/app/obia11g/tmp in the previous blog entry. In order to ensure this new directory is used in place of /tmp, we need to set some more environment variables in ~/.bashrc. Please add the following lines to the obia11g user's .bashrc file above the JAVA_HOME entry you made earlier:
TMP=/u01/app/obia11g/tmp TMPDIR=$TMP TEMP=$TMP export TMP TMPDIR TEMP _JAVA_OPTIONS=-Djava.io.tmpdir=$TMP export _JAVA_OPTIONS
Address the java.policy issue
One of the issues that seemed to start with the application of the OBIA 11.1.1.8.1 BP6 patch was an MBeanTrustPermission issue which occurred when the patch process got to the point where it was patching the ODI repository. This issue is documented in Oracle Doc ID 2017319.1. It is not clear to me whether or not this issue has been resolved in OBIA 11.1.1.10.2, however the Doc ID says the fix applies to 11.1.1.8.1 and greater versions. Therefore, I feel it best to apply the fix described in this document proactively to OBIA 11.1.1.10.2 in order to avoid potential issues down the road.
Application of the fix for this issue is fairly straightforward. All that needs to be done is to open /u01/app/obia11g/java/jdk/jre/lib/security/java.policy in your text editor and add the following line at the bottom of the code contained inside the "grant function" curly brackets:
permission javax.management.MBeanTrustPermission "register";
When done, the file should look like the following:
Once all of this is done, please log off and log back in again. Then issue the following command from the terminal:
$ java -version
If your output resembles the following, then congratulations - you have installed the Oracle Java JDK version 1.7.0_80 successfully.
Summary
In this blog entry, we installed the Oracle JDK version 1.7.0_80 into a directory structure in well-suited to an eventual OBIA 11.1.1.10.2 installation. Furthermore, after the installation we made some changes to some environment variables in the .bashrc file, and we also addressed an Oracle issue in the java.policy file.
Looking ahead
My next blog entry will demonstrate how to silently install the WebLogic 11g (10.3.6) Java EE application server.