Advanced customization of the Oracle installation with ora_profile

Advanced customization of the Oracle installation with ora_profile In our last post, we talked about how to customize a number of settings in our Oracle installation. But what if we wanted to customize the installation itself? Is that even possible? It is, thanks to a number of features in ora_profile. In this article we’ll discuss how to go about customizing the various aspects of our Oracle installation. We’ll also discuss how to provide a different implementation during the install.

Making changes to the installation

Before we can start overriding things on installation, we first need to understand a bit about the ora_profile module, how it makes changes, and when those changes happen.

All the bits to install, create, and populate an Oracle database are in ora_profile::database. These happen in a particular order:

  • sysctl
  • limits
  • packages
  • groups_and_users
  • firewall
  • asm_storage
  • asm_software
  • asm_diskgroup
  • db_software
  • db_patches
  • db_definition
  • db_listener
  • db_services
  • db_tablespaces
  • db_profiles
  • db_users
  • db_startup

The ora_profile documentation explains what each step does, so check that if you need more information before we carry on.

In our imaginary world, our customers have some interesting requirements. They need a file put in place before the packages are installed. They also need some additional users added right after the groups_and_users part of the installation. We’ll do this in two parts.

First, let’s put some files in place before the packages are installed. To do this, we need to add a bit of hiera data that tells the module when to put our files in place, and then we define the files in another class. The data looks like this:

ora_profile::database::before_packages: my_other_class::adding_files

And then we define our files in the other class:

class my_other_class::adding_files (
) {
  file { '/path/to/my/file':
    ensure => present,
    user   => 'oracle',
    group  => 'oracle',
    mode   => '0400',

Next, we need to put in a bit of hiera data to tell the module when and where to manage our other users, and then we’ll define that in another class. The data looks like this:

ora_profile::database::after_groups_and_users: my_other_class::additional_users

Note that you don’t have to do this in the same class as the last part (i.e., my_other_class); you can do this in whichever class you want.

Now we add our other users:

class my_other_class::additional_users (
  $users_array = [ 'aubrey', 'jane', 'timmy' ],
) {
  user { $users_array:
    ensure => present,
    shell  => '/usr/bin/fish',

It’s that easy. And remember, you can put in your own customizations before or after any of the stages listed above.

Using our own implementation

Oh no! Our customers have a last minute request: they don’t want us to manage the db_users parameters. To skip this portion, we simply add the following to our hiera data:

ora_profile::database::db_users: skip

Let’s imagine for a minute that instead of skipping this class, our customers actually want to manage the db_users portion of the installation with their own class. In this case, we use the same hiera parameter, but with a different value, the name of our class:

ora_profile::database::db_users: my_other_class::db_users


In this article, we’ve discussed how to customize your Oracle installation. Previously, we discussed how to setup a database and how to customize a number of settings in that installation. With these tools in hand, you’re now enabled to effectively and efficiently install and manage an Oracle database installation through Puppet thanks to Enterprise Modules’ ora_profile module. Now you have the fun part: putting these newly learned skills to the test.