Securing OHS environments with latest SSL TLS protocols and SHA-2 certificates

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Customer case

A while ago I was contacted by a customer about their old Oracle Application and Weblogic Server environment.
They were receiving complaints from users that they can’t connect to the secure site any longer. Most of the complaints came from users that just recently updated their tablet or smartphone.
After a quick look in the logs of the OHS servers, I found out that the problem had to do with the SSL protocols being used.
The servers were providing connections through either SSLv3 or TLSv1.0, while the devices requested at least TLSv1.1.

The environment comprises of an Oracle HTTP server 10.1.x, for SSO, in front of their Application Server.
For the applications they are using OHS 11.1.1.x. in front of a mix of applications. Varying from oc4j 10.1.2 all the way up to 11.1.1, including Oracle Forms and Reports.
Unfortunately, due to this complexity of components, they were not able to upgrade the environment in time.

SSL Current Situation

SSL Current Situation

 

Requirements

The customer asked to provide a solution with the following requirements.

  • Disable the old, insecure, SSLv3
  • Enable TLSv1.1 and TLSv1.2 for all sites
  • Current hostnames for the url’s must not change
  • Support SHA-2 SSL certificates for all sites

Circumstances I had to take into account

  • Oracle HTTP Server (OHS) 10.1.x and 11.1.1.x do not support TLS 1.1 and TLS 1.2.
    This is due to the Oracle NZ layer used by OHS 10g/11g for its SSL implementation which doesn’t support TLS 1.1/1.2.
  • There is no support for SHA2 certificates (SHA256 or SHA512) or algorithms in Oracle Application Server 10g (10.1.2.X.X/10.1.3.X.X)
  • SHA2 is certified for Fusion Middleware 11g (11.1.1.X) with caveats
  • As part of their SHA-2 migration plan, Microsoft, Google, and Mozilla have announced that they will stop trusting SHA-1 certificates.
    Google will begin phasing out trust in SHA-1 certificates in November 2014.
  • Replacing the old 11.1.1.x OHS with FMW Webtier 12.1.3.0. is not an option.
    OSSO from the 10.1.x appserver is being used and in FMW Webtier 12.1.x the mod_osso module is no longer supported.

note. Oracle Traffic Director on Exalogic is also based on FMW 11.1.1.x !!

Solution

There are several options to meet the requirements set by the customer.
Unfortunately the best solution, upgrading the environment, cannot yet be implemented.

In this case the requirements were met by placing a reverse proxy in front of the entire environment.
The reverse proxy acts as an SSL terminator for client connections using the latest SHA-2 SSL Certificates.
To encrypt the connection, using TLSv1.0, between the reverse proxy and the backend OHS, I generated Self-Signed SHA-1 certificates compatible with the old servers .

As a reverse proxy I had the choice between using Oracle Fusion Middleware 12c 12.1.3 Webtier or the plain Apache HTTP Server.
I decided to go with Apache HTTP Server.

The reason for this choice were.

(Security) Updates – (Security) updates are released more frequent for plain Apache than for Webtier
Easier to maintain – The server will be managed by Linux engineers, not the Oracle Engineers
Smaller footprint – I only need the reverse proxy functionality, not all the fancy stuff that comes with Oracle Webtier.

SSL Installed Solution

SSL Installed Solution

Pretty much all requirements were met by using the latest Apache with the correct SSL settings and new SSL Certificates.

For one requirement we needed to play a little trick:

Current hostnames for the url’s must not change
After setup of the reverse proxy, all DNS entries for the url’s hostnames where changed to the IP-addresses of the reverse proxy.
For the reverse proxy to be able to do its work, I placed the old IP-addresses in the local hosts file of the server running Apache HTTP Server.
So the clients browsers are accessing the url’s via DNS resolving to the reverse proxy which on his turn resolves the hostsnames on the backend using /etc/hosts.

Final thoughts

It was not my intension to describe the complete setup of an Apache based reverse proxy here.
There are tons of how-to’s, blogs, etc. that describe all the setups and features.
The main purpose of this article is to make people aware of the fact that there are some changes in SSL security upcoming that can have a direct impact on your environment.

In the case described above, users were already experiencing problems with mobile devices and tablets. And as I finished the setup, their developers discovered that Java 1.8 uses TLSv1.2 by default.
So a problem, they did not yet relate to SSL protocols, was solved in the process.

As reminder

Oracle supports the use of TLSv1.1 and TLSv1.2 as of version FMW 12.1.x
Oracle supports the use of SHA-2 as of FMW 11.1.1.x (with caveats)

Related Oracle support notes:
Does Oracle HTTP Server (OHS) 10g Or Higher Support TLS 1.1 and TLS 1.2? (Doc ID 1503476.1)
Using OHS 12c With TLS 1.1 and 1.2 Protocols as an SSL Reverse-Proxy to OHS 11g (Doc ID 1920143.1)
Is SSLHonorCipherOrder and TLS 1.1/1.2 Supported for Oracle HTTP Server? (Doc ID 1485047.1)
How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products (Doc ID 1936300.1)

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Oracle Service Bus: Obtaining a list of exposed SOAP HTTP endpoints

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

The Oracle Service Bus is often used for service virtualization. Endpoints are exposed on the Service Bus which proxy other services. Using such an abstraction layer can provide benefits such as (among many other things) monitoring/logging, dealing with different versions of services, throttling/error handling and result caching. In this blog I will provide a small (Java) script, which works for SOA Suite 11g and 12c, which determines exposed endpoints on the Service Bus.Exposed SOAP HTTP endpoints

Continue reading

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Rapid creation of Virtual Machine(s) for SOA Suite 12.1.3 server run time environment – leveraging Vagrant, Puppet and Biemond

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

imageIn recent previous articles I have discussed the use of Vagrant and Puppet for the automated creation of Virtual Machines, for example with various Oracle software components completely installed into them. In this article, I am merely the consumer of goodies. Edwin Biemond published on GitHub the complete set of Vagrant and Puppet configuration files for creating VMs with the SOA Infra database (Oracle Database 11.2.0.4, populated with the RCU installer) and the SOA Suite 12.1.3 run time environment – including Service Bus, see: WebLogic 12.1.3 infra (JRF) with SOA,OSB.

In this article, I will describe the steps I took to actually produce the two VMs using Edwin’s scripts. The visual description of the whole process looks something like the next figure:

image

Prepare your host environment

First of all, prepare your local environment for the use of Vagrant and Oracle VirtualBox, if you have not already done so. The required actions are described in this article –Fastest way to a Virtual Machine with JDeveloper 12.1.3 and Oracle Database XE 11gR2 – on Ubuntu Linux 64 bit – under steps 1 through 4.

Downloaded required software

Next you will have to download the installation files for Java (JDK 7u55), Oracle Database 11.2.0.4, FMW 12.1.3 Infrastructure, SOA Suite 12.1.3 and Service Bus 12.1.3. In my case, all files are downloaded into a single directory:

image

Note:

the file fmw_12.1.3.0.0_infrastructure.jar was extracted from the V44416-01.zip file that I downloaded from eDelivery (for the FMW 12.1.3 Infrastructure)

the files fmw_12.1.3.0.0_osb_Disk1_1of1.zip and fmw_12.1.3.0.0_soa_Disk1_1of1.zip are actually the renamed versions of V44423_01.zip and V44420_01.zip that I downloaded from eDelivery:

image

tips for downloading:

Database

The specific database software for 11.2.0.4 can only be downloaded from Oracle Support at this time. Go to https://support.oracle.com and search for patch 13390677 (also see instructions in this article: http://www.snapdba.com/2014/01/oracle-database-11gr2-11-2-0-4-installation-on-oracle-linux-6-4/). Download the software for Linux x86-64.

image

Then click on Download.

image

Note: you really only have to download two files (out of 7):

image

Java

The Java 7 JDK Update 55 can be downloaded from eDelivery, as part of the Fusion Middleware 12c Media Pack. Alternatively, the download site is: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u55-oth-JPR:

image

make sure you download the JDK for Linux x86-64 (the guest OS) and use the JDK 1.7u55 jdk-7u55-linux-x64.tar.gz file.

The required file JDK 7 JCE policy UnlimitedJCEPolicyJDK7.zip can be downloaded here: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

image

Fusion Middleware

The required files for Fusion Middleware are available from the eDelivery cloud at Oracle: https://edelivery.oracle.com.

Search for Fusion Middleware on platform Linux x86-64:

image

Click on the Oracle Fusion Middleware 12c Media Pack. On the next page, click the Download button for three items:

image

After downloading, extract fmw_12.1.3.0.0_infrastructure.jar from the V44416-01.zip file. Rename V44423_01.zip and V44420_01.zip  to fmw_12.1.3.0.0_osb_Disk1_1of1.zip and fmw_12.1.3.0.0_soa_Disk1_1of1.zip respectively.

Download Edwin’s Configuration Files

You can download the required files from GitHub in a ZIP-archive using: https://github.com/biemond/biemond-orawls-vagrant-12.1.3-infra-soa/archive/master.zip or you can use Git (related tools) and clone the repository at https://github.com/biemond/biemond-orawls-vagrant-12.1.3-infra-soa.git.

We’ll assume a simple download as ZIP file:

SNAGHTML536d840

Extract the content from the zip file to any directory you fancy, for example c:\temp:

image

Edit the Vagrantfile – configure the correct software directory

The Vagrantfile contains two vm.synced_folder definitions – one in the soa2admin2 VM and one in the soadb VM. Ensure that both refer the directory on your host system into which you have downloaded the installation software:

image

image

Note: you may want to set up an additional shared folder for use later on to exchange files between guest (VM) and host.

If your host machine has plenty of memory resources, you may want to extend the memory allocated to the soa2admin2 VM to for example 6GB – as this will give all WLS servers a little more breathing space:

vb.customize [“modifyvm”, :id, “–memory”, “6144”]

 

Create the two VMs using Vagrant

Open a command line window and navigate to the biemond-orawls-vagrant-12.1.3-infra-soa-master directory that was extracted from the GIT zip archive.

Type:

vagrant up soadb

This will start the creation of the first VM – with the Oracle Database 11.2.0.4 environment. The RCU installer is executed during the creation of the second VM and then the SOA Infra database schema are created into this database.

image

In under 10 minutes, the first VM is done:

image

The VirtualBox manager shows the details for this machine:

image

Let’s now have Vagrant create the second VM, with the SOA Suite run time middleware components (and install the SOA Infra database at the same time):

Type:

vagrant up soa2admin2

This will start the creation of the second VM.

image

after 15 minutes and a bit, the second VM is created as well.

image

The VirtualBox dashboard shows its details:

image

Note: configuring the logical names for the two VMs in the Windows hosts file (or whatever your host OS is) is useful as well:

10.10.10.5    soadb.example.com
10.10.10.21    soa2admin2.example.com

(in my case in C:\Windows\System32\drivers\etc\hosts)

Testing the SOA Suite 12.1.3 run time environment

A quick test of our new environment is done from the browser. The middleware VM – soa2admin2 – runs on IP address 10.10.10.21. The WebLogic Admin Server is started and can be accessed through the Admin console – http://10.10.10.21:7001/console – and the Enterprise Manager FMW Control 12c: http://10.10.10.21:7001/em.

image

After logging in with weblogic/weblogic1, the Enterprise Manager dashboard shows up:

image

In the console, we can inspect the details for the three WLS Managed Servers that were created, and we can start them, for example soa_server1

image

Once the soa_server1 is running – listening on port 8001 – we can see this reflected in the EM FMW Control:

image

Note that a sample composite is pre-installed: SimpleApproval.

The SOA Composer application can be accessed at http://10.10.10.21:8001/soa/composer

image

and

image

and likewise the BPM Worklist application for controlling Human Tasks as http://10.10.10.21:8001/integration/worklistapp

image

and

image

The Service Bus Console can be accessed at: http://10.10.10.21:7001/servicebus.

Once the BAM Server (bam_server1) has been started, it listens at port 9001. The BAM Composer runs at http://10.10.10.21:9001/bam/composer; login as weblogic/weblogic1.

Note: there is at present a problem with the BAM Data Source that causes the login to the BAM Composer to fail. This problem can be resolved manually: Locate the BamDataSource under Services/Data Sources. Edit the Data Source: open the Transaction tab and enable the option Emulate Two-Phase Commit. Restart the BAM Server to have this change resolve the login issue.

Exactly the same issues exists for the following Data Sources:wlsbjmsrpDataSource (which prevents Message Reports from being created in Service Bus), EDNDataSource, SOADataSource and OraSDPMDataSource.

The VM cannot at present do name resolution for internet domain names. If you want the SOA Suite to be able to reach out to specific domains (such as www.yoursite.com) you have to add the IP address for the site and its logical name to the /etc/hosts file. I will try to find out how to make the name resolution automatic (somewhere between VirtualBox, Linux and my host environment I think something has to give…)

Database

The database VM (soadb) runs on IP address 10.10.10.5. It hosts an Oracle Database ,Release 11.2.0.4.

The operating system users:

  • root vagrant
  • vagrant vagrant
  • oracle oracle

Welcome01 is the password for the Database users SYS and SYSTEM. (see configuration details in https://github.com/biemond/biemond-orawls-vagrant-12.1.3-infra-soa/blob/master/puppet/hieradata/soadb.example.com.yaml)

Restarting the VMs and Running WebLogic Admin Server

The VMs can be stopped and started using vargant. With

vagrant halt

you will stop both machines.

With

vagrant halt soadb

or

vagrant halt soa2admin2

you will stop the specified VM.

With vagrant up you can start both machines, with vagrant up soa2admin2 or vagrant up soadb you will again start one of the VMs.

Once the soa2admin2 machine is running, you can connect to it, either using vagrant ssh (which will start your locally installed ssh tool in the proper context) or using Putty. In the latter case, connect to 127.0.0.1 and port 2222 – which is forwarded to the VM s0a2admin2.

image.png

Login as vagrant with password vagrant.

To perform the necessary operations, type

sudo su – oracle

To assume the role of user oracle.

Change the directory focus to /opt/scripts/wls:

cd /opt/scripts/wls

And to verify the status of the Node Manager, you can execute

./showStatus.sh

SNAGHTML5dd698a.png

When you discover the Node Manager is not yet running, you can have it started using the following command:

./startNodeManager.sh

It will take a little while, and finally the Node Manager will call in to let you know it is running:

image.pngIf you check the status again, things will look brighter now:

SNAGHTML5e0333e.pngNote: if at this point the Admin Server is not yet running, then use the next command to have it started:

./startWeblogicAdmin.sh

And from the browser on the host, we can connect again to Admin Server and the other started managed servers

http://10.10.10.21:7001/console

 

Setting up connnections in JDeveloper

To work with this splendid environment, it is useful to have connections in JDeveloper to the Application Server and the MDS Service.

Create an Application Server connection to:

  • Username weblogic; Password weblogic1
  • WebLogic Hostname 10.10.10.21
  • Port 7001 ; SSL Port 7002
  • WebLogic Domain: soa_domain

Create an MDS Database Connection to:

  • name soadb_dev_mds (suggested)
  • user dev_mds; password Welcome01
  • Driver thin
  • Host Name 10.10.10.5; JDBC Port 1521
  • Service Name: soarepos.example.com

And an MDS Connection based on this Database connection:

  • Connection Name soa2admin2_soadb (suggested)
  • Connection Type: DB Based MDS
  • Connection: soadb_dev_mds
  • Select MDS Partition: soa_infra

Note: a database connection to user SYS in the soadba database can be created to:

  • user sys; password Welcome01; role SYSDBA
  • Driver thin
  • Host Name 10.10.10.5; JDBC Port 1521
  • Service Name: soarepos.example.com

 

Kudos

As always – big kudos to Edwin Biemond for sharing his Vagrant & Puppet configuration with the community. Once all downloads are done, you can create the VMs with a complete running SOA Suite 12c environment within 30 minutes waiting time (and with less than one minute of your personal time. Impressive!

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Fastest way to a Virtual Machine with JDeveloper 12.1.3 and Oracle Database XE 11gR2 – on Ubuntu Linux 64 bit

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

In a previous article I have explained in quite a bit of detail how to create the Vagrant and Puppet scripts for stamping out a Virtual Box VM with Oracle Database XE 11gR2 and JDeveloper 12.1.3 (with ADF 12.1.3) on top of Ubuntu (64bit Linux): https://technology.amis.nl/2014/07/29/creating-automated-jdeveloper-12-1-3-oracle-xe-11gr2-environment-provisioning-using-vagrant-and-puppet/. If you want to learn a little more about Vagrant and Puppet, that might be an interesting read. However, if you do not need to go into the mechanics, and just want to get going as quickly as possible with a VM with said contents, the article you are reading now is what you need. Following the shortest route to a running VM – that is all we care about. Not about what has gone into the scripts and tools we indirectly make use of.

The process can be visualized like this:

image_thumb.png

The steps are (described for Windows 7 – but basically the same on any platform):

1. Download Vagrant

Download the installer for Vagrant from https://www.vagrantup.com/downloads.html (the latest version at the time of writing is 1.6.3)

image

For Windows this is a simple Windows installer (154 MB):

SNAGHTML95b7ff9

2. Install Vagrant on your local file system

Run the msi file downloaded in the previous step:

SNAGHTML96c5310

And click your way through the simple, straightforward and well known steps:

SNAGHTML96cb79c

SNAGHTML96cc717

SNAGHTML96cd9ad

SNAGHTML96cecb0

SNAGHTML96d00db

SNAGHTML96d277e

After clicking finish – the installation is complete.

A little unfortunate: you have to restart your system for the installation to be really done:

SNAGHTML96dea7e

After the restart, you can verify the success of installing Vagrant by opening a command line and typing: vagrant -v:

image

3. Download Oracle Virtual Box

Download the VirtualBox installer from http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html – the latest version at the time of writing is 4.3.1.4. Note: you need to download for the host platform (in this article that is Windows) not the guest OS.

image

SNAGHTML95e4af5

4. Install Oracle VirtualBox

Run the exe file downloaded in the previous steps:

SNAGHTML972e705

Click your way through the installer – the steps are self guided:

SNAGHTML9733c36

SNAGHTML9734ff4

SNAGHTML9735f9e

SNAGHTML973712b

SNAGHTML973822b

SNAGHTML9739241

Acknowledge the following question that pops up several times:

image

SNAGHTML974b433

 

5. Download the Oracle Database XE installer

Download the Oracle Database XE installer from Oracle Database 11gR2 XE – note: in this case we need the version for Linux 64 because the database will be installed into the Guest aka the VM, running 64 bit Linux:

image

SNAGHTML9621075

6. Download JDeveloper installer for Linux from Oracle Technology Network

Download the JDeveloper installer from Oracle JDeveloper 12.1.3 for Linux 64 bit

image

Again, because this software is installed into the Guest VM, we need to download the Linux installer – not the installer for the [Windows] host.

SNAGHTML963bbe0

7. Download the Vagrant and Puppet configuration files from GitHub

You can download the requires files from GitHub in a ZIP-archive using: https://github.com/lucasjellema/adf-12-1-3-vm/archive/master.zip or you can use Git (related tools) and clone the repository at https://github.com/lucasjellema/adf-12-1-3-vm.git.

We’ll assume a simple download as ZIP file:

SNAGHTMLc35fd

Extract the content from the zip file to any directory you fancy, for example c:\temp:

image

8. Move the installation resources for JDeveloper and Oracle Database XE to staging directory

Copy the installation resources for JDeveloper and Oracle Database XE – that were downloaded in steps 5 and 6 to the files directory under the adf-12-1-3-vm-master directory

image

9. Create the VM using Vagrant

Open a command line window and navigate to the adf-12-1-3-vm-master directory that was extracted from the GIT zip archive.

Type:

vagrant up

this will fire off Vagrant, based on the Vagrantfile you extracted from the GIT zip archive

image

The first time, the base box precise64 is not yet locally available, so it will be downloaded. This file is around 300 MB, so this action will take a while – depending on your internet connection.

Note that this step will run completely automatically – no manual intervention is required. Just sit back and relax for the next 15-20 minutes and your VM will be baked for you.

image

In VirtualBox, the new VM will be listed:

image

10. Run the VM with VirtualBox

Log in to the VM as vagrant/vagrant.

SNAGHTML265466

Note: you will be able to access APEX in a browser – either running inside the VM (at http://localhost:8080/apex) or in the host, thanks to port forwarding: http://127.0.0.1:8888/apex. To login to the (internal) administration page for APEX, use admin/oracle as the credentials.

Run JDeveloper: to run JDeveloper, click on the top icon on the desktop and type jdev as search string. The JDeveloper icon appears. (note: you can drag the icon to the launcher bar on the left)

Click it and JDeveloper is started.

image

The launch image is shown:

image

You have to reply to familiar dialogs:

image

image

and finally JDeveloper’s IDE appears.

image

Perhaps create database connection

Show the Resources window (using the menu entry under Windows) and add a new IDE Connection of type Database:

image

Configure the database connection – easy enough with username and password equal to wc and the default values for Driver, Hostname and SID equal to the ones we need. Press Test Connection to enjoy the success message. Then press OK to close the dialog.

image

In the Connections Navigator, you can verify which database objects have been created in the final stages of the provisioning actions (a few tables and one user defined type):

image

Run Integrated WebLogic Server

image

Configure the WebLogic Server details:

image

And press OK to create the domain:

image

In this case, the domain configuration took very long (over 30 minutes) – I hope that does not prove typical. Note: a second attempt required about 13 minutes – more reasonable.

After creating the domain, the Integrated WLS is started:

image

And in the local Firefox browser, the Administration Console can be opened.

image

Note: The WebLogic Console can also be accessed in a browser running on the host: using http://127.0.0.1:7501/console, you will be able to access the console – and of course other applications running on the Integrated WebLogic Server.

Summary

The Virtual Machine is not ready in a flash. First you have to perform five downloads and two installations. This takes time – but very little manual intervention. Note that two downloads and the two installations are one time only: Oracle VirtualBox and Vagrant can be reused many times, for different VMs. The downloads of the Oracle Database installer and the JDeveloper installer are unavoidable. Once all files are downloaded and a simple archive is expanded, you only have to type a simple command line instruction and the actual installation is done for you.

I have not exactly timed the whole process – as I was writing the article while going through the motions. Of course the exact timing depends on your network speed. My guess would be:

  • Download time: 40-60 minutes (no manual intervention required once started)
  • Vagrant VM creation time: 15 minutes ( no manual intervention required once started)
  • Manual actions (installations, explode archive, move files, run Vagrant): 5-10 minutes

Your personal investment is about 15 minutes. Once Vagrant and Oracle VirtualBox are installed, the effort is reduced to less than 10 [and close to 5]minutes.

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Creating automated JDeveloper 12.1.3 & Oracle XE 11gR2 environment provisioning – using Vagrant and Puppet

Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page

Standing on the shoulders of many smart and persistent friends, peers and colleagues, I was able to fairly quickly concoct the Vagrant and Puppet configuration that allows automated provisioning of a VirtualBox VM that runs Ubuntu (64bit Linux) with Oracle Database XE 11gR2 and JDeveloper 12.1.3 (with ADF 12.1.3). With a few command line actions, the creation of a clean and preconfigured VM is done in the background. image

This article gives a brief description of how I put together the configuration for Vagrant and Puppet to install Oracle Database XE and JDeveloper. The final picture looks like the figure.

Note: I started from the excellent contribution by Michael Medin (see GitHub: https://github.com/mickem/adf-12c-enviornment ) and tweaked his configuration just a little to support JDeveloper 12.1.3 (instead of 12.1.2). My own contribution was very limited – although by doing it my understanding has increased substantially. The work done by my colleagues Jaap Poot and Edwin Biemond has been extremely valuable (especially their recent article for Java Magazine, the Magazine for the Dutch NLJUG).

Edwin Biemond has been the greatest inspiration in getting excited about Vagrant, Puppet and bascially provisioning in general. Big kudos!

The only external requirements or preparations are:

  • download and install Oracle VirtualBox (see resources)
  • download and install Vagrant (see resources)
  • download the Oracle Database 11gR2 XE installation file – oracle-xe-11.2.0-1.0.x86_64.rpm.zip
  • download the Oracle JDeveloper 12.1.3 installation file – jdev_suite_121300_linux64.bin
  • fetch the sources discussed in this article from GitHub, either by cloning the repository using Git or by downloading the sources as a zip-file – https://github.com/lucasjellema/adf-12-1-3-vm

Steps:

  • download all and install some of the prerequisite stuff (see above)
  • create a new Vagrant project (a folder, a generated configuration file and a few manual alterations) => this is enough to create a bare bones VirtualBox VM image
  • configure the Vagrant file to use Puppet as a provider => this means that Puppet is added to the VM image and the specified Puppet resources are executed from within the VM after it is built and started
  • create the Puppet main manifest file – base.pp in this case => this file references the classes and resources that are required for the VM; initially this file will do very little at all – the real work is added once we create modules for installing the XE database and JDeveloper
  • create the Puppet module for installing the Oracle XE database (based on Michael Medin’s work) and include the classes from this module from the base.pp main manifest file => at this point we can run Vagrant to create the Linux VirtualBox image with the XE 11gR2 database inside (including the unlocked HR schema)
  • create the Puppet module for installing Oracle JDeveloper 12.1.3 (based again on Michael Medin’s work) and include the classes from this module from the base.pp main manifest file => at this point we can run Vagrant to create the Linux VirtualBox image with the XE 11gR2 database inside as well as JDeveloper
  • create a bonus Puppet module to install a sample database schema with tables and demo data

Create the VirtualBox image with Vagrant

The first step is a very simple one. We will use Vagrant to help us create (automatically) a VirtualBox image with Ubuntu 64-bit Linux set up. This local image is based on one of the predefined Vagrant boxes published on the Vagrant website: Ubuntu precise 64 VirtualBox, at http://files.vagrantup.com/precise64.box.

Create folder adf-12_1_3-environment (somewhere on your file system) with a subfolder files.

Open command line, change directory to adf-12_1_3-environment and type

vagrant init

This will create the Vagrantfile that provides the starting point for the environment we are going to provision.

Edit the Vagrantfile to specify the appropriate base box to use (one with 64 bit Ubuntu prepared for VirtualBox as provider) and configure the forwarded posts, allocated memory, the synched folders and the provisioning to be performed into the Virtual Machine using puppet:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

config.vm.box = "precise64"
# this VM is based on the predefined box precise64 that is available from the following URL
# note: the box will be downloaded (330 MB) from that URL if Vagrant cannot not find it locally (in the Vagrant home - by default: HOME/.vagrant.d/boxes))
config.vm.box_url = "http://files.vagrantup.com/precise64.box"
config.vm.hostname = "adf12-1-3.amis.sandbox"

# any network request on the host made to the specified port (8888 or 1521) should be forwarded into the VM and handled there
config.vm.network :forwarded_port, guest: 8080, host: 8888
config.vm.network :forwarded_port, guest: 1521, host: 1521

config.vm.synced_folder "files", "/etc/puppet/files"
config.vm.synced_folder "files", "/vagrant", :mount_options => ["dmode=777","fmode=777"]
# the next line is supported from Vagrant 1.6 onwards; it displays a message on the command line after "vagrant up" has brought up the VM
# config.vm.post_up_message = "Virtual Box is running. You can connect using username vagrant with password vagrant."
config.ssh.forward_agent = true

config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "4096"]
vb.gui = true
vb.name = "JDeveloper 12.1.3 with Oracle Database XE 11gR2 on Ubuntu"
end
end

At this stage you can have a VirtualBox VM created with Ubuntu Linux and initialized:

vagrant up

The following output is produced in the command line terminal:

image

The VM is created and started.

image

You can login to it using the user vagrant with password vagrant

image

The VM environment does not have a graphical desktop. Nor does it have either Oracle Database XE or JDeveloper in it at this point – despite the name of the VM. That is what Puppet will do for us.

The VM does already have folders – such as /vagrant – mapped to the files folder on the host machine.

image

Visually, the following has taken place:

image

Install Vagrant and VirtualBox. Create Vagrantfile. Run vagrant up to have Vagrant process the Vagrantfile, download the Precise64 box and interact with VirtualBox to create the VM according to specifications, including a folder mapping from /vagrant in the VM to the files subfolder in the host.

To remove this incomplete VM, simply type

vagrant destroy

and confirm your intention.

image

Engage Puppet to perform provisioning tasks on the VM

Create folders manifests and modules under adf-12_1_3-environment . These folders will contain the configuration files for Puppet.

image

Add these lines to the Vagrantfile:

config.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.module_path = "modules"
puppet.manifest_file = "base.pp"
end

image

They instruct Vagrant to run Puppet from within the VM image – starting with the base.pp manifest file (in the manifests sub-folder) and merging the included classes from [the manifests from]all modules (remote and the local subfolders under the the modules folder).

Create a file called base.pp in the folder adf-12_1_3-environment\manifests. Puppet is engaged by Vagrant because of the config.vm.provision configuration in the Vagrantfile. This configuration refers to these directories for manifests and modules. It also refers to file base.pp (in the manifests directory) as the starting point for the actions to be executed by Puppet.

Add the following content to the base.pp file:

package { "build-essential": ensure => present }
package { "ubuntu-desktop": ensure => present }

group { "oracle":
ensure => present,
}

file { "/home/vagrant/importantFileForSomething.txt":
ensure => present,
source => "/etc/puppet/files/someTestFileToBeCopiedToTheVM.txt",
owner => "vagrant",
require => Package["ubuntu-desktop"],
}

exec { "restart-lightdm":
command => "/usr/bin/apt-get install linux-headers-$(uname -r); /etc/init.d/lightdm restart; /usr/bin/touch /etc/puppet/.lightdm",
creates => "/etc/puppet/.lightdm",
subscribe => Package['ubuntu-desktop'],
}

# apt-get update downloads the package lists from the repositories and "updates" them to get information on the newest versions of packages and their dependencies
# see: for example http://askubuntu.com/questions/222348/what-does-sudo-apt-get-update-do
exec { "apt-update":
command => "/usr/bin/apt-get update"
}
Exec["apt-update"] -> Package <| |>

Here we define a number of resources. One is package {“ubuntu-desktop”} ; through that resource, we ensure that Puppet sets up the graphical desktop in our VM. Another resource creates a Linux group (called oracle). The file resource is configured to copy a file called someTestFileToBeCopiedToTheVM.txt from the shared folder /etc/puppet/files – which maps to the files folder on the local, host file system – to the folder /home/vagrant inside the VM. Create that file as a simple text file in the files folder – so when we run Vagrant again, we will see its result.

Now run again the command

vagrant up

After the VM is created, Vagrant passes control to Puppet to provision the additional elements inside the VM. Notice how two additional shared folders are created by Vagrant to accommodate Puppet in accessing the manifests and modules directories in the host:

image

Also note how Puppet figures out the order in which to execute the resources – based primarily on the require  attribute that indicates mutual dependencies between resources.

This time, a Virtual Box image is created that has a graphical desktop – as was instructed by the base.pp resources. It takes a lot longer than before (400+ seconds) – as the creation of the graphical desktop is not a simple little task. It contains the Firefox browser and the LibreOffice suite among other tools.

image

We can check if the file someTestFileToBeCopiedToTheVM.txt was indeed copied to the VM and put in the /home/vagrant folder as importantFileForSomething.txt:

image

Extending our previous visual overview of what happened with the Puppet contribution, we get the following figure:

image

The Vagrantfile is extended with a line that engages Puppet from the VM. The modules and manifests folders are created with the base.pp file in the manifests folder. This file instructs Puppet to install the Ubuntu desktop and copy a file. Note that Vagrant will automatically add folder mappings for the modules and manifests folders.

Engage Puppet to perform the installation of Oracle Database XE and JDeveloper

Time for some even heavier lifting. Our objective is to install two pieces of Oracle software in the VM: Oracle Database XE 11gR2 and JDeveloper 12.1.3. We need the installation files for that and we need to configure Puppet to perform the installation. We will create to Puppet modules for this – oracle_db and oracle_jdev.

Create a directory files under adf-12_1_3-environment and copy the downloaded files jdev_suite_121300_linux64.bin and oracle-xe-11.2.0-1.0.x86_64.rpm.zip to this directory. This directory is available from within the VM through the synched_folder definitions in the Vagrantfile.

image

base.pp will soon include several classes from two modules: oracle_db (for the XE installation) and oracle_jdev (for the JDeveloper installation). It also includes a number of [Puppet] resources of its own – entries that will prompt Puppet to inspection and possibly action to ensure the target environment is or will become as specified in the resource definition.

Puppet configuration for the installation of Oracle Database XE 11gR2

The installation of Oracle Database XE 11gR2 using Puppet has been described and realized by several authors, including Michael Medin and Matthew Baldwin (https://github.com/matthewbaldwin/vagrant-xe11g). I have based my scripts on those published by Michael, especially because he also went on to have Puppet provision JDeveloper (12.1.2 in his case).

I have made a few fairly small changes to Michael’s scripts. One thing is the teardown class that I added to remove from the VM the intermediate files used during the install process (to free up disk space).

For the installation of Oracle Database XE, we work with a module called oracle_db. For this module, a directory with the name of the module should be created. Inside this folder are subfolders files, manifests and templates:

image

Folder manifests contains file init.pp – the file that defines the classes and the resources used for the installation of the Oracle Database XE. This file defines five classes – server, swap, xe, hr_schema and teardown. These classes are supported by several files in the module subfolders files and templates. In the former are files that are used literally in the VM; in the latter are templates that [may]contain references to Puppet variables; these variables are dynamically resolved into the actual values before the contents of the template is used to create a file inside the VM.

image

and templates:

image

In this latter template, the password to be used for the HR schema is defined through a variable reference: <%= @hrPassword %>. The reference @hrPassword indicates the $hrPassword variable that is defined in the init.pp file in the oracle_db module:

class oracle_db::config {

$group = "dba"
$hrPassword = "hr"
$sysPassword = "oracle"
}

Class server paves the way for the installation performed by class xe. In server, all Linux dependencies are prepared as is the file system. Class swap prepares the swapfile. Finally, class xe does the actual installation. It unzips the downloaded installation file oracle-xe-11.2.0-1.0.x86_64.rpm.zip (this creates the Disk1 subfolder in the home directory for user vagrant), turns the RPM (not supported on Ubuntu) into a deb file (using alien) and then installs the software package for Oracle Database XE based on that deb file. Then, the resource configure xe can do the real installation – using the response file /tmp/xe.rsp, created from the xe.rsp file in the files directory of module oracle_db.

Class hr_schema uses SQLPLUS to unlock the HR database schema and to set the password for this schema to hr. Note that in the original setup by Michael Medin, this class was part of the oracle_jdev module.

Class teardown – my addition to the work from Michael – removes the /home/vagrant/Disk1 directory when the installation is done (resource “configure xe”), deletes the .deb file created by the “alien xe” resource and removes the .zip file.

The classes in the oracle_db module are now to be included in the main manifest file base.pp in order to do actually be engaged. This is done with the following include lines:

include oracle_db::server
include oracle_db::swap
include oracle_db::xe
include oracle_db::hr_schema
include oracle_db::teardown

Note: class hr_schema inherits from class config. Class config does not have to be explicitly included in base.pp to still be available & accessible.

Three additional resources are added to base.pp to create/configure user oracle, set the password for user oracle and create the home directory for user oracle. Note how the creation of the user is made to depend on the resource Service[“oracle-xe”]. That is a resource defined in class oracle_db::xe – and this is a trick to force the Oracle Installer to create the user oracle with all the required attributes. The user resource will further append to this user.

Once Vagrant is done and Puppet has also completed its provisioning work,

image

you can start the VM, logon as vagrant, open the Firefox browser and type the URL localhost:8080/apex into the location bar. This should bring up the login page for Application Express (APEX) 4.0:

image

Note: because of the port forwarding that was specified for the Virtual Machine in the Vagrantfile, you can also access APEX from the host. When you enter http://127.0.0.1:8888/apex in the address bar of a browser running on the host, you will get the same result as in the browser running inside the VM. Note that in Vagrantfile we mapped port 8888 to 8080.

The visual description of the provisioning process:

image

The Puppet module oracle_db is introduced, its classes included from base.pp. The Oracle Database XE installation file was downloaded from OTN and copied to the files subfolder. Puppet processes the new classes, causing the Oracle Database XE 11gR2 software to be installed.

Puppet configuration for the installation of Oracle JDeveloper 12.1.3

The installation of Oracle JDeveloper 12.1.3 using Puppet is an extension of the work by Michael Medin on JDeveloper 12.1.2. I have taken Michael’s scripts and adapted them for JDeveloper 12.1.3 (a very minor change to be exact).

Create folder modules/oracle_jdev (for module oracle_jdev) with child folders files, manifests and templates as shown:

image

Folder manifests contains the init.pp that describes the Puppet resources that specify the final state of the VM once JDeveloper 12.1.3 is installed. Remember that earlier on we already copied the JDeveloper installer file (jdev_suite_121300_linux64.bin) to folder adf-12_1_3-environment/files. This file is obviously going to play a role now when the actual installation of JDeveloper takes place.

Here is the contents of the init.pp file – largely taken from Michael Medin’s example:

class oracle_jdev::config {
$group = "dba"
$mdwHome = "/u01/app/oracle/product/12.1.3/jdeveloper"
$oraInventory = "/u01/app/oracle/oraInventory"
$hrPassword = "hr"
$sysPassword = "oracle"
}

class oracle_jdev::install inherits oracle_jdev::config {

include oracle_jdev::config

file { "silent_jdeveloper.xml":
path => "/tmp/silent.xml",
ensure => present,
replace => 'yes',
content => template("oracle_jdev/silent_jdeveloper_1213.xml.erb"),
}

file { "/etc/oraInst.loc":
ensure => present,
content => template("oracle_jdev/oraInst.loc.erb"),
group => "dba",
mode => 0664,
require => Service["oracle-xe"],
}
file { "/usr/share/applications/jdeveloper.desktop":
ensure => present,
content => template("oracle_jdev/jdeveloper.desktop.erb"),
require => Package["ubuntu-desktop"],
}
file { "/usr/share/pixmaps/jdeveloper.png":
ensure => present,
source => "puppet:///modules/oracle_jdev/jdeveloper.png",
}
file { ["/u01/app/oracle/product"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { ["/u01/app/oracle/product/12.1.3", "/u01/app/oracle/product/12.1.3/jdeveloper"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}

exec { "installjdev":
command => "/etc/puppet/files/jdev_suite_121300_linux64.bin -silent -responseFile /tmp/silent.xml -invPtrLoc /etc/oraInst.loc -ignoreSysPrereqs",
user => "oracle",
require => [File["/etc/oraInst.loc"], File["/u01/app/oracle/product/12.1.3/jdeveloper"]],
creates => "/u01/app/oracle/product/12.1.3/jdeveloper/jdeveloper/",
timeout => 0,
}

exec { "change_directory_permissions":
command => "/bin/chmod -R 777 /u01/app/oracle/product/12.1.3",
user => "oracle",
require => Exec["installjdev"],
timeout => 0,
}

}

class oracle_jdev::connections inherits oracle_jdev::config {

include oracle_jdev::config

file { ["/u01/app/oracle/.jdeveloper",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model/connections"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => [Service["oracle-xe"],Exec["installjdev"], Exec["change_directory_permissions"]],
}
file { "/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model/connections/connections.xml":
ensure => present,
content => template("oracle_jdev/connections.xml.erb"),
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
}

Some folders and file name were renamed to better reflect the 12.1.3 release as compared to the 12.1.2 that the original file supported. A new logo (jdeveloper.png) was created for JDeveloper 12.1.3 and copied to the files directory in module oracle_jdev. Note how this image is copied into the VM and how it is referenced from the Desktop item that is created using template jdeveloper.desktop.erb in the templates directory for module oracle_jdev.

The crucial resource of course is installjdev that will perform the actual installation. It runs file jdev_suite_121300_linux64.bin – that is available inside the VM from the shared folder /etc/puppet/files. It feeds a response file to the installer (/tmp/silent.xml) that was created from the local template silent_jdeveloper_1213.xml.erb in an earlier file resource. Note that because the installer is ran from a shared folder, it is not actually created in the VM anywhere and therefore does not have to be removed after the installation.

I had some issues with running JDeveloper as user vagrant (because of the directory privileges as set by the Oracle Installer – all assigned to user oracle) and with running JDeveloper as user oracle because of problems with the X11 Windows Server (user oracle could not connect to the GUI). My somewhat crude but effective solution was to simply open up the directories created for the installation of JDeveloper, using the change_directory_permissions resource type. (it is not going to win me any awards, but for such as a simple R&D VM I think I can get away with it).

To ensure that the module oracle_jdev is actually activated, the relevant class(es) have to be included in the main manifest file. Edit manifests/base.pp and add this line:

include oracle_jdev::install

This is all it takes to bring in all the resources inside the install class in the oracle_jdev module.

The console log reports on the JDeveloper installation actions performed by Puppet:

SNAGHTML61df852

Visually, the entire provisioning process is described in the next figure:

image

The Puppet module oracle_jdev has been added and included from base.pp. The Linux installer for JDeveloper 12.1.3 was downloaded from OTN and copied to the files subfolder. Puppet processes the resources from the new module, causing JDeveloper 12.1.3 to be installed.

The result from all this activity

After putting all the folders and scripts together, we can give Vagrant one final swing and have it stamp out our VM image. It runs for approximately 900 seconds in my case (15 minutes) and creates the VM, installs Oracle Database XE (cleans up after itself) and installs JDeveloper 12.1.3.

Log in to the VM as vagrant/vagrant.

image

To run JDeveloper, click on the top icon on the desktop and type jdev as search string. The JDeveloper icon appears. Click it and JDeveloper is started.

image

The launch image is shown:

image

You have to reply to familiar dialogs:

image

image

and finally JDeveloper’s IDE appears.

image

Bonus: Creation of sample database schema

In order to be able to quickly create a sample application, it is useful to have some sample data available. As part of the Puppet actions that provision the platform in our VM image, it is little trouble to also have one or more SQL scripts executed against the Oracle Database XE 11gR2 that is installed in the earlier stages of the process. I have created a simple Puppet module with a single manifest file and three SQL files to create a sample schema – in this case with data from the recent World Cup Football.

A new module is created simply by  creating a new folder in the modules folder:

image

This new folder oracle_amis_sample contains two sub-folders: files and manifests. Folder files contains the SQL scripts we will copy into the VM image:

image

sys-ddl.sql is executed as sys and creates a new user WC with some system privileges. Files ddl.sql and dml.sql are executed by this new user WC and create objects – such as tables – and data.

The manifest file init.pp in the oracle_amis_sample/manifests folder contains the Puppet resources that describe the transfer and execution of these files. The file defines a class oracle-amis-sample that will be included from the main manifest file: base.pp. The class contains three entries based on the file resource type; these copy files from the files folder in the [local]Puppet module definition to the /u01/app/oracle/scripts folder inside the Virtual Machine. Three other entries are of resource type exec and use SQLPLUS inside the VM to execute a SQL script. Note that the require attribute has been specified to ensure the SQL scripts are executed in the proper order: sys-ddl first, then ddl and finally dml.


class oracle_amis_sample::install {

file { "/u01/app/oracle/scripts/sys-ddl.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/sys-ddl.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { "/u01/app/oracle/scripts/ddl.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/ddl.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { "/u01/app/oracle/scripts/dml.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/dml.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
exec { "create_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"sys/$sysPassword as sysdba\" @/u01/app/oracle/scripts/sys-ddl.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [File["/u01/app/oracle/scripts/sys-ddl.sql"], Service["oracle-xe"]],
}
exec { "ddl_in_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"wc/wc \" @/u01/app/oracle/scripts/ddl.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [Exec["create_wc_schema"]],
}
exec { "dml_in_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"wc/wc \" @/u01/app/oracle/scripts/dml.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [Exec["ddl_in_wc_schema"]],
}

}

Note: the reference puppet:///modules/oracle_amis_sample/ddl.sql refers to the ddl.sql file in the files child folder under the oracle_amis_sample module. This is by convention: puppet:/// references are resolved against the files subdirectory under the specific module folder.

The base.pp is extended ever so slightly to leverage the new module. All it takes for the oracle-amis-sample module to be included in the provisioning process is the following line:

include oracle_amis_sample::install

Puppet will scan the modules directory for subfolders that contain modules. It will scan the manifests folder inside each module for the definitions of classes and resources. There it finds the oracle_amis_sample::install class defined in the init.pp file in the oracle_amis_sample module. This class is added to the catalog through the include command in base.pp. That is enough to make the resources in oracle_amis_sample/manifests/init.pp be realized.

If we now run

vagrant destroy

followed by

vagrant up

a new VM will be created that has the sample WC schema installed with tables and data in it.

image

When the VM is created and initialized, login as vagrant and run JDeveloper again – as described above. One thing you may want to do now: leverage these sample objects and data:

Show the Resources window (using the menu entry under Windows) and add a new IDE Connection of type Database:

image

Configure the database connection – easy enough with username and password equal to wc and the default values for Driver, Hostname and SID equal to the ones we need. Press Test Connection to enjoy the success message. Then press OK to close the dialog.

image

In the Connections Navigator, you can verify which database objects have been created in the final stages of the provisioning actions (a few tables and one user defined type):

image

The final visual overview of the entire provisioning process:

image

One more Puppet module was introduced: oracle_amis_sample. The files folder for this module contains the SQL scripts that Puppet will execute inside the VM against the Oracle Database XE 11gR2 instance.

Resources

The GitHub repository with the sources described in this article: https://github.com/lucasjellema/adf-12-1-3-vm.

Getting started with Puppet – on line tutorial

Getting started with Vagrant – on line tutorial

Download and install Vagrant

Download and install/configure Puppet

Download and install Oracle VirtualBox

Download Oracle Database 11gR2 XE

Download Oracle JDeveloper 12.1.3 for Linux 64 bit

Blog article by the Puppet Master Edwin Biemond, introducing Vagrant (and Packer) in combination with Oracle Virtual Box: http://biemond.blogspot.nl/2013/11/creating-your-own-virtualbox.html

Blog article on Java Mon Amour on using the path variable with Exec resource type (to refer to /bin directory): http://www.javamonamour.org/2013/10/puppet-exec-always-requires-path.html

    Blog article by Andreas Koop: Setup WebLogic 12c environment with Vagrant and Puppet – with a great graphic depicting the provisioning of a WebLogic 12c VM:

    image

    Blog article on downloading sources from Git by a Puppet action from within the VM – http://livecipher.blogspot.com.au/2013/01/deploy-code-from-git-using-puppet.html

    Documentation on VBoxManage – listing all properties that can be passed to modify the VM (and that can be set in Vagrant files using vb.customize) : https://www.virtualbox.org/manual/ch08.html

    Vagrant Base Box for Oracle Enterprise Linux 6.5 – https://github.com/terrywang/vagrantboxes/blob/master/oraclelinux-6-x86_64.md

    Share this on .. Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someoneShare on TumblrBuffer this page