Oracle Analytics Server (OAS) 5.9 is available for many months now and it brought some features updates to OAS 5.5 (released in 2020) as expected by the “one new features release per year” plan for OAS (compared to cloud receiving new features updates multiple times per year).

If you look at the What’s New for Oracle Analytics Server page, the very first point is that you can deploy OAS on Oracle Cloud: an interesting first new feature for a product intended to be the on-premises offering for Oracle Analytics. The real point is more that OAS can be deployed wherever you want as long as the requirements are met. Your server in your basement, a cloud compute instance: it is the same thing for OAS, you are in charge of installing, configuring, and maintaining it, but you can run it anywhere you like.

There is a TL;DR version of this post at the end. It’s a two-pieces blog posts: first how you can deploy the Oracle Analytics Server Marketplace stack, second why you maybe don’t want to use this stack.

And before to say that I’m doing some Oracle bashing, I do really like Oracle Analytics Server. It’s a great product and brings some of the recent new feature of Oracle Analytics Cloud on-premises while keeping all the power and customizability of OBIEE,

The issue is the packaged images in the Marketplaces, not the product itself.

What that “new feature” tries to highlight is that Oracle published 2 applications in the Oracle Cloud Marketplace:

  • Oracle Analytics Server – UCM (universal credits)
  • Oracle Analytics Server – BYOL (bring your own license)

The difference between the two is the licensing: if you own a valid license for OAS, you can run it without paying licenses again (the BYOL version). If you don’t own any Oracle Analytics license you can use the product by paying an extra hourly cost, on top of the compute instance costs, covering the licensing fees (the UCM version).

It does look like a fantastic idea to have OAS in the Marketplace as it could allow users to easily get OAS up and running either for testing or as a real work environment with the benefits that cloud computing can bring (no need to buy and maintain hardware, flexibility by adding or removing instances easily, multi-region redundancy possible, etc.).

Let’s give it a try…

A stack that doesn’t do much

When reading through the short overview of Oracle Analytics Server in the Marketplace, there is a list of system requirements:

  • A separate Oracle Database instance is required to host system schemas
  • VCN and subnet required for stack deployment

First bad surprise: this is a stack that will automagically (the power of Terraform) setup OAS, but it will only care about the OAS compute instance and everything else has to be set up beforehand.

You must prepare the networking in the compartment where you plan to deploy this instance, and you also must make sure to have a supported database accessible from that virtual cloud network (either in a compute instance or by using a DBaaS instance or an external database; Oracle Autonomous Database isn’t supported at the moment for the system schemas).

Make sure to not overlook the little reminder below the “Launch Stack” button: “Reminder: Patch the instance once installed.”

Yes, it’s up to you to apply the latest bundle patch available and any other security patch (like for Log4j just to name a recent one).

Launching the stack

When you launch the stack the process is the typical one for any stack: you go through a kind of wizard that asks you to provide the mandatory information to prepare the instance for your usage, and once all the info is available the system will apply the Terraform stack that will create and configure all the required pieces (based on what the author of the stack did code and prepared).

First some generic values for stack itself (the stack will be available in the Oracle Resource Manager, the cloud service allowing to manage stacks: applying one to create the required instances or destroying it to remove all the pieces created by a stack).

The second step is all the values (variables) required by the OAS instance that the stack will create. 

OAS will be deployed in a compute instance and that’s why the first part is all about configuring the compartment, availability domain, the shape of the compute instance (if you select a “flex” shape you are also prompted for the number of OCPU and the amount of memory), the boot volume size (disk size) of your compute instance and finally the SSH key to allows you access to the instance.

It’s important to note here that the minimum boot volume size is 1024Gb!!! No idea why they need 1Tb of disk space for a product that could fit into 10-15Gb on disk.

By the way, you will pay for 1024Gb of disk space at least, but inside the compute instance the boot volume has not been expanded to cover the whole size and only the default volume size of 39Gb will be available.

Follows the setup of the networking for the OAS compute instance. Remember that you need to have your VCN already created. The settings here are only selecting an existing VCN and a subnet. If the subnet is a public one you can also decide if you want to assign a public IP address to the compute instance, making it accessible from outside the Oracle Cloud virtual network without the need of a VPN or bastion host.

Finally, the settings that are really OAS-related: the minimum amount of details to configure OAS and create the domain. You can also skip this part but, if you do, you will need to configure OAS yourself before trying to use it as only the binaries will be installed.

Username and password of the administrator account in OAS, the database details: connection string, username and password of an account with administrative privileges, a prefix to be used for the schemas that will be created by OAS, and a password these new schemas will use.

The last step is a review of all the information you provided in the previous steps. A chance to verify everything. You can also directly check the checkbox “Run Apply” to start the creation of the stack when you press the “Create” button. If you don’t check that checkbox you will be taken to the stack page where you can review all the values you provided, edit them, etc. (all the things you can do with a stack).

Creation isn’t done when it says it’s done

Creating the stack is pretty fast, after a few minutes the stack will be marked as fully created. If you look for the compute instance you will find it and you will be able to log in by SSH.

This doesn’t mean OAS is ready to use: the compute instance is there, but the OAS configuration is still in progress. It will take many more minutes for OAS to be fully configured and started.

To know if it’s done, you can check for the existence of the file /tmp/oas_install.finish : if the file doesn’t exist it means the process isn’t done. There is also a log file that you can keep an eye on: /tmp/oas_install.log. This isn’t an OAS log file, it’s the log of cloud-init, the tool used by the stack to finalize the configuration inside the compute instance once it has been created.

What is inside the OAS Marketplace compute instance?

The compute instance is based on a cloud Oracle Linux 7.9 image, inside are installed the binaries for Oracle Java JDK 8 and OAS (WebLogic and the Fusion Middleware 12.2.1.4 and OAS 5.9). It is based on a custom cloud image that has the binaries installed by default, the install isn’t part of the creation of the stack, only the configuration can be. The response files used for installing both the WebLogic Fusion Middleware 12.2.1.4 and OAS 5.9 are available if you want to see what parameters have been used, you can find them in /oas/oas_install : wls.rsp for the FMW and biplatform.rsp for OAS.

The only real parameter at this point is ORACLE_HOME=/oas/oas_install/Oracle/Middleware/Oracle_Home, everything else is the default value. To this point, not a big deal…

I’m maybe picky, but it’s such a mess

I had quite some concerns about the quality of this OAS stack available in the Marketplace only by seeing the stack itself (you can download the Terraform stack from the Resource Manager).

A person at Oracle, when asked about the target of this stack said: “The idea is to provide a ‘template’ that customers and partners to tailor to specific needs.”.

Let me say it now in full words: DO NOT USE THIS THING AS A TEMPLATE!

This OAS compute instance is an example of a good idea, poorly prepared, and badly executed. The list of reasons why this isn’t a template is long…

I already mentioned that you are forced to create a 1024Gb boot volume but the image only sees 39Gb of total available space (while you pay 1024Gb).

The Fusion Middleware documentation says, as a good practice, to place the domain’s directory outside of the ORACLE_HOME where the binaries are installed. The reason is fairly simple: during an in-place upgrade you provide the new version binaries and keep the domain (after upgrading it). If you have the domain inside the ORACLE_HOME, after an in-place upgrade you will have two different ORACLE_HOME: the new one for the new version of the binaries, and the old one that you can’t delete because the domain is inside. This is why the response file for the OAS configuration explicitly asks for a location where to place the domain. This image uses DOMAINS_DIR=/oas/oas_install/Oracle/Middleware/Oracle_Home/user_projects/domains , placing the domains right inside the ORACLE_HOME (/oas/oas_install/Oracle/Middleware/Oracle_Home).

Everything is installed as the “opc” user, the default account provided in Oracle Linux cloud images. This user has sudo privileges!

It’s now a week that Log4j vulnerabilities are in the news, it started with what has been called Log4Shell, a severity 10 vulnerability that easily gave remote access to a server. Remember how this instance isn’t patched yet, it’s still full of vulnerable Log4j packages. If somebody uses a vulnerability to gain access to the server and execute code, they will be running as a user with sudo (without password) privileges. A good practice would have been to create another account with limited permissions owning the product, even just an “oracle” user for that (in a typical on-premises setup, you don’t install and own OAS with your personal account but use a system account for that).

The used Java 8 is old, it is version 1.8.0_211 when nowadays 1.8.0_311 exists. In an Oracle Linux cloud instance Oracle JDK can be installed and updated via a YUM repository, it would be simple to install the most recent Oracle JDK 8 at the time the stack is setup.

OAS exposes various services through various ports. As with any other Linux environment, there is a firewall installed that, by default, block all these ports. What this stack does is create a firewall service and open all the ports defined by the service. That’s a good way to easily open or close all the ports for an application like OAS, so where is the problem? Well … the service opens some useful ports, some useless ports, and forgets to open some other useful ports. It does look like the person who wrote that firewall service did merge the ports used by OBIEE 10g, OBIEE 11g and OBIEE 12c with some of the ports used by OAS and called it a day!

In the firewall the ports 9500-9508 for protocol TCP will be open, these are some of the default ports required to fully use OAS. Do you want to connect with the Model Administration Tool client to develop or edit the RPD? You need port 9514 as well! Apparently, somebody at Oracle forgot the RPD is a thing after years of self-service propaganda. It doesn’t stop here, ports 7001, 9704, and 9556 are also open: there isn’t any process listening on these ports out of the box. Please do correct the firewall settings of your instance if you use it.

Your database administrative username and password used to configure OAS are in full text in a file left on disk. Right next to the OAS administrator username and password. Remember how I said the response files used for the installation are still there? The same applies to the response file used for the configuration, the file containing, in clear text, all this sensitive information. You can find it in /oas/oas_install/biconfig.rsp .

The default behavior of OAS is to automatically start all the components at the end of the configuration. Therefore once the job is done you will have access to your OAS. But this image doesn’t come with any service managing OAS: if you want to stop the compute instance (for any reason), you will need to manually stop OAS (to prevent issues because of stopping the compute instance with a running OAS). And you guessed it: at the start of the compute instance OAS will not run, you will need to manually start it.

Keeping it simple: you take an Oracle Linux, you install Oracle Java 8, you install OAS with default settings, open some (random) ports and this is what this stack is like. Do you really need a stack for that?

How should this OAS on Marketplace be instead?

This OAS on Marketplace is a great missed chance to provide a state-of-the-art installation of OAS. Separating the binaries and the domain, with a folders structure easing in-place upgrades. Focusing on security by using a dedicated user to own and run the product, opening the correct minimum amount of ports in the firewall.

In nowadays web applications SSL is a must! Configuring SSL in OAS is possible, but it’s a bit of a cumbersome process dealing with keystores, etc. It would have been possible to pre-package a lightweight reverse proxy inside the image forwarding requests for TCP 80 and 443 to the OAS front-end. Something like nginx that I believe was (is?) used in OAC as well. 

So, should you use this OAS on Marketplace stack?

It is now more than 13 years that I do use Oracle Analytics products. Over the years I didn’t fully agree with some of the Oracle’s choices or products, but in general, it was mainly positive aspects with some downsides. This is the first time that I struggle to find a benefit, something justifying why you would want to use this OAS on Marketplace stack. Keep in mind: Oracle Analytics Server is great, the issue is how it has been packaged into these Marketplace stacks.

I believe the only positive aspect is: it does exist.

If you have no idea about Oracle Analytics you better try Oracle Analytics Cloud, the Oracle managed cloud offering. 

If you already have OBIEE or OAS on-premises and want just test for 1-2h how it behaves in a cloud compute instance, then it could work for you for a quick test experimenting more with the cloud networking and security set up.

If you have no idea how to install OAS and want to learn, look somewhere else (even only at a Docker install of OAS 5.9 to see commands and options). Read the documentation and you will know enough to install your OAS correctly without the mistakes done in this image.

If you look for a base image on which to develop (for example setting up a cluster or anything else), look somewhere else or install it yourself. It will take you 1h max to have a clean compute instance image installed by script (or with an Ansible playbook). You can use Terraform to setup the whole stack (including networking and database) and execute your script on top of a clean Oracle Linux image.

TL;DR

Keep away from this thing! How can Oracle, who developed this stack, not know that OAS doesn’t use ports 7001 and 9704 anymore? How can they not know their own good practice about folders structure?

It looks like the nowadays situation, with Oracle Analytics fully focused on self-service in their Oracle Analytics Cloud, makes them forget about how the product really works. But it’s all written in their own documentation. Maybe they copied what OAC images are like, the difference is that nobody has access to an OAC image and it’s fully managed by Oracle (is it a mess? Their problem, they have to deal with it, not you).

I can’t find good aspects in this stack, it’s poorly done, that’s it! It’s a template of how to not install an OAS server.

Share This