Wouldn’t it just be your luck that you go to install OBI 11g and during the pre-requisites check one of the sections fail, you choose to ignore it, and then a week later your OBI server goes down because you forgot to flip a switch or change a setting from the very beginning?  This post attempts to help alleviate that from becoming your fate by speaking to the only part of the OBIEE 11g pre-requisite on Linux that continually fails during my installations.  I’m speaking about the Kernel parameters pre-req check:

You can Google the hard/soft nofiles kernel parameters and their purpose because I will not explain it here.

Ultimately these configuration settings are stored in the /etc/security/limits.config file.  You will need to work your VI editor skills to add two lines for the linux user you are conducting the OBI 11g install with.  If you look at my screenshot below you see that I had previously updated this file for the “oracle” user.  That is the user that I used to install the Oracle 11gR2 RDBMS on that machine prior to my OBI 11g install.  Update the file similar to mine – at least meet the limit for which the pre-req check seeks.

Rebooting the machine is the easiest way I found to ensure the settings get impacted.  I’ve tried just refreshing (clicking the back button on the install wizard) the pre-req check while in-stride but that didn’t work after the change was made.  That left me with the quick reboot option which wasn’t a big deal in my environment.

After the machine came back up, I restarted the OBIEE 11g installation and as you can see below all pre-reqs passed at 100% which nice glowing green check marks.  The install continued and all was good.

Let it be know that when it comes to X Windows technology and connecting a from Windows workstation to a remote Linux/Unix machine, my support goes to XMing.  Now that is not to say that XMing doesn’t have its issues like all other XWindow client technologies.  But it is clean, it offers a nice install package and provides, in the world of open source, very good documentation.  And as a real quick refresher for those that don’t do much Linux or Unix, it is a best practice to lock down your servers and limit connectivity only to those that really need access. That being said, Linux and Unix when being installed have the option of being installed with a GUI interface for the OS or not.  Often times the really astute (geeky) IT pros select the latter and no GUI access is available.   More to the point, in order to install such software as required by Oracle and some other software teams, only a GUI interface such as the Oracle Universal Installer, is available. To accomplish the install on the remote computer from a Windows workstation you need an X Windows client, such as XMing.

Confronted the other day with just such an install, Oracle client and the Datawarehouse Administration Console (DAC), I put my good friend XMing to work.  Let’s talk about that for a moment.  When using XMing, I choose to use it with a solid telnet tool that we all know and love, PuTTy.  PuTTy basically has a setting to forwards the X11 (X Windows) from your remote session to your local/workstation machine.  Ultimately connecting is accomplished in a few steps:

1. Set the DISPLAY var of your remote user profile to the IP of the machine/workstation you are remoting from. many examples on the web show “localhost” but if you are conducting a VPN session to a remote Windows server then you may not be able to get away with just localhost and will need to enter the exact IP of that machine on the network.  For example, if you workstation you are on has an IP of 216.55.55.55 then enter that IP address suffixed with “:0.0″ (e.g.: 216.55.55.55:0.0) in the DISPLAY var of your remote user profile.  Also enter this in the “X Display Location” of your PuTTy session.
2. Execute the command xhost + and/or xhost + IP address
3. Before you need to run a GUI program from the remote linux/Unix machine, launch XMing’s XLaunch application.
   • As a gotcha to this, you may need to select the option to enable “No Access Control” in order to by pass connectivity errors from the workstation rejecting requests from the remote server.

Recently my need to install the Datawarehouse Administration Console (DAC) cause me issues on a VPN session for a remote connect to a Linux server.  Ultimately after completing the above major steps in initiating an X Windows session, the when I ran the installer command for the software, the X Windows session would start and disappear.   It would stay visible just long enough for the OUI (Oracle Universal Installer) to start and haphazardly enough when I clicked the “Next” button to continue the install the X Window would close as would the XMing application.  I checked the logs and the logs only noted successfully connectivity and GUI transfer from the remote machine.  No errors were in the log.

Ultimate what fixed the issue was for me to launch a session of the XLaunch application and before I ran the installer command from the remote PuTTy session window, I right clicked on the Windows Taskbar icon for XLaunch and opened the log file.  I left the log file open and then executed the install command in my PuTTy session.  Somehow some way the X Window and the GUI remote install stayed alive  and I was able to complete the installation.  I think that somehow the XMing application was getting hit with some exception that would otherwise cause it to abend but due to the log file being open, the main application could not close.  Or, something like that.  I was using XMing version 6.9.0.3.1 for this implementation.