Wednesday, September 30, 2015

Automation for DBA - Ansible part 1


In this post I would like to move forward with software provisioning and configuration. In my last post I covered a ways to build a "core VM" and now it's a time to add some software and configuration to it.

There are couple of automation tools, which can be used for that task like Puppet, Chef or Ansible to name a few. The latter one - Ansible - is my favorite, cause in my opinion it has shortest learning curve and also doesn't require any agents on the remote servers.
Although there are some requirements which has to be met on the remote servers:
- ssh connectivity to the remote host
- Python 2.4 ( with python-simplejson ) or 2.5 installed on the remote host.

If Python is a "big no-no" in your organization, you can still you Ansible to help you run a script over set of servers but you will loose almost all functionality.

How Ansible works:

Ansible has a concept of the control machine and a remote managed servers. Ansible scripts are started on the control machine and other servers are managed over a SSH connection and Ansible modules send to the remote servers on demand. Ansible can run in the fully automated mode only if control machine and remote servers has a password-less SSH configuration. In the other case Ansible can ask for a SSH password.

The control machine can be a dedicated sever or it can be an OS admin or DBA laptop, where Ansible is installed. Please check Ansible documentation to find a information how to install it. 

Remote servers can be managed from control machine, only if they are added into a Ansible inventory. The inventory is a text file with the following format:

envtest ansible_ssh_host= ansible_ssh_user=oracle


There are two groups in inventory file - testdbgroup with one members envtest, and proddb-group with two members rac1 and rac2. Server - testdb - is listed in the inventory file but it not a part of any group. 

Ansible has a concept of host and group variables. 
Group variables are used for all host defined in the a group. There is a directory called group_vars, containing a files named with a group name. Each file is a set of variables for a particular group.
Host variables are used for a particular host only and they overwrite a group variables. There is a directory called host_vars, containing a files named with a host name. Each file is a set of variables for a particular host.

$ ls -l host_vars/
total 24
-rw-r--r--  1 mprzepiorowski  staff  29 Sep 29 12:44 envtest

$ cat host_vars/envtest
password: "host env password"

$ ls -l group_vars/
total 8
-rw-r--r--  1 mprzepiorowski  staff  23 Sep 29 13:10 testgroup

$ cat group_vars/testgroup
groupname: "Test group"
Server envtest has a file with host variables and it belongs to the group testgroup with a defined variables as well. Both will be used in the following example. 

Running mode
There are three ways of running a remote command:
- single command mode, 
- Ansible playbooks
- Ansible playbooks with roles
and commands or playbooks can be run on the specific host from inventory file, specific group or all hosts.


Single command:

In the first run Ansible can be used to add SSH public key from control machine into remote server. By default Ansible connect to the remote servers using a user running a command on the control machine, but this can be changed in the inventory file.
$ cat inventory/lab
envtest ansible_ssh_host= ansible_ssh_user=oracle
Remote server has a user oracle and it will be used by all scripts. If remote server name "envtest" is not resolved by a DNS, IP address can be added to inventory file as well.

Test a SSH connection to remote host
$ ssh oracle@
oracle@'s password:
Password is required and this is an example command to fix this problem

$ ansible -k -i inventory/lab all -m authorized_key -a "user=oracle key=\"{{ lookup('file', '/Users/mprzepiorowski/.ssh/') }}\" "
SSH password:

envtest | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD43SwP3zXR/LrKqADJDC8jUOv0vgMEQVqWOXoUgwlzQ1vpS1I5m3GjXggG7fjU5I2jGbG+V9xSqPZdw4MGed4nsgOo1m68w9oBpfYLu3hKACSw1Tgu8Ghxd5TB9ohyZ7NOgepXB+zmV8NoqvAUg4yDkk4qPn1fQmoIz7yLkPRErnmSkI6e/gHsGAmZ+5WdvH0FByPCMEfHqDe8vI4ZPVbPWZzl5x9m72HtxjCbB2htHg1JEcch6927oiRE9rllbOL0M/tw5LgjCtYpM3iZTsBwFsGZ6NQ1DM+OiJSrDEhUqUMOZ08X/G7aNYb28QUt9G/FZTTwZjEfnOO75n3i29U/ mprzepiorowski@Marcins-MacBook-Pro.local",
    "key_options": null,
    "keyfile": "/home/oracle/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "present",
    "unique": false,
    "user": "oracle"
Command options:
- k - ask for SSH password
- i inventory/lab - use a inventory file from folder inventory and file name called lab
all - run this command for all hosts from inventory file
-m authorized_key - use Ansible module authorized_key
- a "user=oracle, key=xxxxxxxx" - Ansible module parameters 

Command output:
- changed : true - remote system has been changed due to Ansible call
- envtest | success - action returned OK status
- other lines are depend on the module

Ansible returned OK status so now SSH connection should work without password:
$ ssh oracle@
Last login: Mon Sep 28 15:58:24 2015 from
[oracle@envtest ~]$
Ansible did a work and SSH public key has been added to user configuration on the remote server. 

Single command is a nice feature if you want to run single command across fleet of servers, but for most of cases Ansible playbook will be a way to deal with.

Ansible playbook:

Next example will show how to create a simple playbook with an one task and install a vim package using yum

Playbook file is formatted in YAML and it looks like this:
- hosts: all
     - name: install vim
       sudo: yes
       yum: name=vim state=present
Be aware that YAML file syntax include a white space, so format of this file matter as well.

Line description:
Hosts: all - mean run a playbook for all hosts from inventory file
tasks: - is a start of task lists (one task in this example)
name: - start of task definition
sudo: - run this module using sudo
yum: - module name with parameters (name is a package to install, state=present mean install it)

Ansible playbook can be stated using this command:
$ ansible-playbook yum.yml -i inventory/lab

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [envtest]

TASK: [install vim] ***********************************************************
changed: [envtest]

PLAY RECAP ********************************************************************
envtest                    : ok=2    changed=1    unreachable=0    failed=0

Where -i is pointing to the inventory file and yum.yml is a name of file with playbook definition. Output contains a list of tasks executed and summary with number of successes, changes and failures. 

Ansible playbook and variables:

In the all previous examples, only has host has been used and there was no variables set. Let's add some more complexity to playbook and show how flexible is Ansible. Both variables defined for particular host and group will be used to create a text file based on template.

Template file ( Ansible supports Jinja2 template language)
$ cat template.j2
Host name is {{ ansible_hostname }}
Host var password is set to {{ password }}
Group var groupname is set to {{ groupname }}

Ansible playbook:
$ cat template.yml
- hosts: all
     - name: generate scripts
       template: src=template.j2 dest=/tmp/output mode=0644

Running playbook:
$ ansible-playbook -i inventory/lab template.yml

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [envtest]

TASK: [generate scripts] ******************************************************
changed: [envtest]

PLAY RECAP ********************************************************************
envtest                    : ok=2    changed=1    unreachable=0    failed=0
Output file on envtest server
$ ssh oracle@
Last login: Tue Sep 29 12:29:59 2015 from
[oracle@envtest ~]$ cat /tmp/output
Host name is envtest
Host var password is set to host env password
Group var groupname is set to Test group
[oracle@envtest ~]$

If you think that Ansible is difficult at that stage, and there is no use for DBA's wait until next blog post when I will use a ansible-Oracle playbooks to install Oracle on server changing only one files with a variables. 




Sunday, September 20, 2015

Automation for DBA - Vagrant part 2


In the last post I presented steps to create Virtual Machine using Vagrant with Virtual Box. It is a native combination but there are other possibilities as well. This post will cover an integration of Vagrant tool with KVM hypervisor and AWS EC2 cloud.

In both cases, an additional plugins has to be installed:
-    vagrant-libvirt plugin for KVM -
-    vagrant-aws plugin for EC2 -

If there is a requirement to use a Vagrant boxes defined for other hypervisors, there is a plugin called vagrant-mutate, which help you to convert it from one format to another.

KVM installation steps:

Host configuration:
-    Fedora 21
-    QEMU emulator version 2.1.

List of plugins is maintain on this page - Available-Vagrant-Plugins

Vagrant has very easy way to manage plugins. If plugin is listed on the official page installation process is limited to single command.

[pioro@piorovm]$ vagrant plugin install vagrant-mutate
Installing the 'vagrant-mutate' plugin. This can take a few minutes...
Installed the plugin 'vagrant-mutate (1.0.1)'!

[pioro@piorovm]$ vagrant plugin install vagrant-libvirt
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
Installed the plugin 'vagrant-libvirt (0.0.30)'!
Displaying a list of installed plugins with version.
[pioro@piorovm]$ vagrant plugin list
vagrant-libvirt (0.0.30)
vagrant-mutate (1.0.1)
vagrant-share (1.1.4)
As in the previous post a prebuild box racattack/oracle65 will be used. This box has been defined for Virtual Box so it has to be downloaded and migrated into KVM format. There is one caveat – after conversion new box will be still using a SATA drivers and not a native virtio drivers. If performance of Vagrant box is important, I will recommend creating a new native version of box for KVM configured with virtio.

Box racattack has two versions in official repository and mutate plugin was unable to use it directly. To workaround that issue a box has to be downloaded first using ex. wget. 
[pioro@piorovm ~]$ wget
--2015-08-19 23:33:57--
Resolving (,
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: [following]
--2015-08-19 23:33:58--
Resolving (
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: [following]
--2015-08-19 23:33:58--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1185789020 (1.1G) [application/octet-stream]
Saving to: ‘’
In the next steps it will be renamed, converted and added to box's repository.
[pioro@piorovm ~]$ mv

[pioro@piorovm ~]$ vagrant mutate libvirt
Extracting box file to a temporary directory.
Converting racattack from virtualbox to libvirt.
Cleaning up temporary files.
The box racattack (libvirt) is now ready to use.

[pioro@piorovm ~]$ vagrant box list
homeora65 (libvirt, 0)
precise32 (virtualbox, 0)
racattack (libvirt, 0)
Vagrant configuration is ready and a new Virtual Machine can be created. Like in the previous host a new directory will be created and a Vagrant will be initialized. In the next step a VM will be started.
[pioro@piorovm ~]$ cd test
[pioro@piorovm test]$ vagrant init racattack
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`` for more information on using Vagrant.
[pioro@piorovm test]$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Uploading base box image as volume into libvirt storage...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              test_default
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              1
==> default:  -- Memory:            512M
==> default:  -- Base box:          racattack
==> default:  -- Storage pool:      default
==> default:  -- Image:             /VM/d1/images/test_default.img
==> default:  -- Volume Cache:      default
==> default:  -- Kernel:
==> default:  -- Initrd:
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     5900
==> default:  -- Graphics IP:
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        9216
==> default:  -- Keymap:            en-us
==> default:  -- Command line :
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Configuring and enabling network interfaces...
==> default: Rsyncing folder: /home/pioro/test/ => /vagrant
[pioro@piorovm test]$
There is a difference how files are synchronized between Vagrant and a VM machine in VirtualBox and other providers. Virtual Box is using a shared directory feature and KVM and EC2 are using rsync. Rsync process is started only once during VM start, and it to synchronize files after that “vagrant rsync” command has to be run

Like I mentioned in previous post, there are differences in Vagrant configuration between hypervisors. 

The following example is showing a configuration which will add two disks:
 - 10 GB none shared disk and 
 - 20 GB disk which can be shared between hosts. 

Memory size is set to 4 GB and number of vCPUs is set to 2. 
VM will have two network interfaces - one bridged to host network card (192.168.1.x) and one private KVM network (10.10.10.x)

Vagrant.configure(2) do |config| = "racattack "

  config.vm.provider :libvirt do |libvirt|
 libvirt.storage_pool_name = "pool_d1"
        libvirt.cpus=2 :file, :size => '20G', :format => 'qcow2 :file, :size => '10G', :type => 'raw', :allow_existing => 'true', :bus=> 'scsi', :device=>'sda', :path=>'asmdisk1_2'

  config.vm.define :host do |host|
         host.vm.hostname = "targetkvm" :public_network, :dev => "br0", :mode => "bridge", :type => "bridge", :ip => "" :private_network, :libvirt__network_name => "private", :ip => ""

This is all about KVM for now but I believe this is a good starting point for experiments.

EC2 configuration

AWS integration with Vagrnat is based on plugin as well. The main difference is that Vagrant box is limited to a file definition and VM is based on AMI delivered by AWS.
This AMI image can be official AWS build, community one or the one created by you.

Installation of the additional plugin:

$ vagrant plugin install vagrant-aws
Installing the 'vagrant-aws' plugin. This can take a few minutes...
Installed the plugin 'vagrant-aws (0.6.0)'!
List of all plugins
$ vagrant plugin list
vagrant-aws (0.6.0)
vagrant-share (1.1.4, system)
Let's create a new directory and configure an EC2 container to start
$ mkdir awstest
$ cd awstest/
$ vagrant init
In the next step a VM has to be configured. This is example Vagrantfile
Vagrant.configure("2") do |config|

  # for AWS use dummy box = "dummy"            

  config.vm.provider :aws do |aws, override|
    aws.access_key_id = "KEY_ID"
    aws.secret_access_key = "SECRET_ACCESS_KEY"
    aws.instance_type = "t1.micro"
    aws.security_groups = "quick-start-1"
    aws.keypair_name = "mykeys"
    aws.region = "eu-west-1"

    # this is official CentOS AMI
    # agree to CentOS license -
    aws.ami = "ami-42718735"

    override.ssh.username = "root"
    override.ssh.private_key_path = "/tmp/mykey.pem"

    aws.block_device_mapping = [{ 'DeviceName' => '/dev/sdb1', 'Ebs.VolumeSize' => 50 }]
Next step is easy "vagrant up" will start your EC2 instance
$ vagrant up
Bringing machine 'default' up with 'aws' provider...
==> default: Warning! The AWS provider doesn't support any of the Vagrant
==> default: high-level network configurations (``). They
==> default: will be silently ignored.
==> default: Launching an instance with the following settings...
==> default:  -- Type: t1.micro
==> default:  -- AMI: ami-42718735
==> default:  -- Region: eu-west-1
==> default:  -- Keypair: mykeys
==> default:  -- Security Groups: ["quick-start-1"]
==> default:  -- Block Device Mapping: [{"DeviceName"=>"/dev/sdb1", "Ebs.VolumeSize"=>50}]
==> default:  -- Terminate On Shutdown: false
==> default:  -- Monitoring: false
==> default:  -- EBS optimized: false
==> default:  -- Assigning a public IP address in a VPC: false
==> default: Waiting for instance to become "ready"...
==> default: Waiting for SSH to become available...
==> default: Machine is booted and ready for use!
==> default: Rsyncing folder: /tmp/awstest/ => /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mkdir -p '/vagrant'

Stdout from the command:

Stderr from the command:

sudo: sorry, you must have a tty to run sudo
Instance is up and running. There was a problem with a rsync as there is problem with SUDO configuration in this AMI. It can be resolved but this is not an issue for this post. Let's try to ssh to EC2 VM now
$ vagrant ssh
[root@ip-10-105-167-95 ~]# ls -l /dev/x*
brw-rw----. 1 root disk 202, 64 Sep 20 10:43 /dev/xvde
brw-rw----. 1 root disk 202, 81 Sep 20 10:43 /dev/xvdf1
SSH to EC2 with Vagrant is very simple. You don't need to remember that is a public IP of EC2 instance, "vagrant ssh" will do a trick. 
To stop EC2 instance use "vagrant halt" and to delete EC2 instance use "vagrant destroy"

This is all I would like to share in this post. In the next one, I will use Vagrant with VirtualBox and I will show how to add an automatic Oracle installation to your VM.


Wednesday, August 19, 2015

Automation for DBA - Vagrant part 1

Vagrant is an open source tool for building a virtual environment. It is based on text based configuration file and concept of prebuilt OS boxes.
One can find a lot of boxes on Atlas webpage (, ready to download and use.  Although if there are any security concerns about using a OS from 3rd party webpage, I published a blog post about creating a new Vagrant box using Oracle Linux here and Oracle Virtual Box.

For simplicity of this series, predefined Linux box will be used in all examples.
There are two boxes that I’m using in my own work.
First one “kikitux/oracle6-racattack” created by Alvaro Miranda ( member of Rac Attack team. The other one is “racattack/oracle65” created by Jeremy Schneider who is also member of RacAttack team.

Vagrant itself is not a Virtualization provider. It can control different virtualization tools, including:
-    Virtual Box
-    AWS EC2 (with an additional plugin)
-    KVM (with an additional plugin)
-    VMWare Fusion / Workstation (paid version of Vagrant)

Most of the differences between providers are hidden by Vagrant workflow, and a configuration file defining a Vagrant box is similar between different providers.
Vagrant user is using same set of commands to start, stop or destroy virtual machine and does not have to know which provider is used for that.

There is a list of typical Vagrant commands:

-    vagrant init – creating a basic configuration file
-    vagrant up – starting a virtual machine
-    vagrant halt – stopping a virtual machine
-    vagrant destroy – delete a virtual machine
-    vagrant ssh – open a ssh session to vagrant user on virtual machine

After this short introduction let’s get started with a Vagrant on Laptop/Desktop (using Virtual Box as a provider)

-    vagrant software –
-    Virtual Box -

In the first step a new directory will be created and used for Vagrant to initiate build of new virtual machine.

mkdir machine1
cd machine1

In the next step Vagrant machine will be initialized

vagrant init racattack/oracle65
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`` for more information on using Vagrant.

A new Vagrantfile has been created with basic configuration. By default Vagrant is trying to change a default set of public / private key with a new pair generated on user machine. But there are some problem with that on latest version of Vagrant, so as a workaround please add this line to Vagrantfile (see

config.ssh.insert_key = false

This is how Vagrantfile looks like without commented lines

Vagrant.configure(2) do |config| = "racattack/oracle65"
    config.ssh.insert_key = false

Now this machine can be started. If a box selected in an init stage is not existing yet in the provider catalog, it will be automatically downloaded and cloned to a new machine.

mprzepiorowski$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'racattack/oracle65' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'racattack/oracle65'
    default: URL:
==> default: Adding box 'racattack/oracle65' (v14.11.01) for provider: virtualbox
    default: Downloading:
==> default: Successfully added box 'racattack/oracle65' (v14.11.01) for 'virtualbox'!
==> default: Importing base box 'racattack/oracle65'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'racattack/oracle65' is up to date...
==> default: Setting the name of the VM: machine1_default_1439847872931_79029
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => /Users/mprzepiorowski/Documents/machine1
Is this that simple? Yes it is – a new virtual machine with Oracle Linux is installed and ready. Next step is to ssh into a new created machine. There is no need to know neither a password nor an IP address,

mprzepiorowski$ vagrant ssh
[vagrant@oracle6-racattack ~]$ 

Now it is a time to customize this machine a little bit. Before that an existing machine has to be stopped using a Vagrant command

mprzepiorowski$ vagrant halt
==> default: Attempting graceful shutdown of VM...

As it was mentioned at the beginning of the post, Vagrant is using a text based configuration file. All customizations can be done by editing this file.
The configuration file structure can be divided into two sections.
First section defines a provider configuration and this part will change when a provider will be changed. Other section is provider independent and describes all other parameters.

Vagrant.configure(2) do |config|

# this part is common for all providers = "racattack/oracle65"
  config.ssh.insert_key = false
  config.vm.hostname = "machine1"

# provider specific configuration

  config.vm.provider "virtualbox" do |vb|
    vb.memory = 1024 
    vb.cpus = 2


Starting a machine with a new configuration

mprzepiorowski$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'racattack/oracle65' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Mounting shared folders...
    default: /vagrant => /Users/mprzepiorowski/Documents/machine1
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

Checking changes

[vagrant@machine1 ~]$ free
             total       used       free     shared    buffers     cached
Mem:       1020696     121356     899340          0      10980      42100
-/+ buffers/cache:      68276     952420
Swap:      8191996          0    8191996
[vagrant@machine1 ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1

All looks good there. Virtual machine has 1 GB of RAM and two vCPU. Machine name has been changed to machine1 as well.

The last change tested here will be a new disk assigned to virtual machine. The box used for an example already has a “sdb” device and an “u01” file system defined inside a box. In this case device “sdc” will be added to the box and can be configured later as a “u02” file system if necessary. The file system creation and configuration will be presented in the next posts about Ansible.

disk_filename = 'disk-u02.vdi'

Vagrant.configure(2) do |config|

# this part is common for all providers = "racattack/oracle65"
  config.ssh.insert_key = false
  config.vm.hostname = "machine1"

# provider specific configuration

  config.vm.provider "virtualbox" do |vb|
    vb.memory = 1024
    vb.cpus = 2
    unless File.exist?(disk_filename)
       vb.customize ['createhd', '--filename', disk_filename, '--size', (5*1024), '--variant', 'Standard']
    vb.customize ['storageattach', :id, '--storagectl', 'SATA Controller', '--port', 2, '--device', 0, '--type', 'hdd', '--medium', disk_filename]


Options specified in vb.customize are options of VBoxManage command of Virtual Box installation.

mprzepiorowski$ vagrant ssh
Last login: Mon Aug 17 22:01:36 2015 from
[vagrant@machine1 ~]$ ls -l /dev/sdc*
brw-rw---- 1 root disk 8, 32 Aug 17 22:25 /dev/sdc
[vagrant@machine1 ~]$ 

New disk is added and ready for other activities.

This is end of this post and I will present similar steps for KVM and EC2 virtual machines in the next one.


Monday, August 10, 2015

Preparing a Oracle Linux for a Vagrant box

This post is an overview of an installation and configuration process of the Oracle Linux, which will be used as a machine “box” for Vagrant software using a Virtual Box platform.

Post itself is divided into two parts:

  1. Oracle Linux installation (points 1 to 12)
  2. Vagrant box configuration (points 13 to 16)

Part 1 – Oracle Linux installation


1. Create a new Virtual Machine - machine name will be used later to create Vagrant box

2. Set memory size - it does matter only for a installation process, as it can be changed later by Vagrant

3. Create a new disk, which will be used to keep a root and a swap file systems only. Any additional disks will be added dynamically via Vagrant. In this example, a disk size is set to 8 GB.

4. Mount Oracle Linux DVD into Virtual Machine drive

5. Configure 1st network interface to be NAT 


6. Add port forwarding for SSH

6.Start Virtual Machine and start a Oracle Linux installation. Some of the screens have been skipped in this post but a default values have been used for those ones.

7.Choose language and keyboard

8.Configure disk using a default basic definition

9.Configure a host name for a box, configure a network with DHCP and start up at boot time.

10.Default packages will be installed only at this time. Some will be added later.

11.Wait for process to be completed

12.Restart machine

Part 2 – Vagrant box configuration

13. Add Vagrant related configuration
  • Add user "vagrant" with password "vagrant"
  • Add Vagrant public insecure public key to .authorized_keys
  • Install Guest additional tools
Connect to VM using ssh
ssh -p 2022 root@localhost
The authenticity of host '[localhost]:2022 ([]:2022)' can't be established.
RSA key fingerprint is 3e:4f:bd:ca:45:d6:e8:d4:6b:4d:02:bb:1f:c3:ad:a2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:2022' (RSA) to the list of known hosts.
root@localhost's password:
Last login: Sat Jul 18 21:25:57 2015 from
Add user using password vagrant
[root@oelbox ~]# useradd vagrant
[root@oelbox ~]# passwd vagrant
Changing password for user vagrant.
New password:
BAD PASSWORD: it is based on a dictionary word
BAD PASSWORD: is too simple
Retype new password:
passwd: all authentication tokens updated successfully.
Add Vagrant public key
[root@oelbox ~]# su - vagrant
[vagrant@oelbox ~]$ mkdir .ssh
[vagrant@oelbox ~]$ chmod 700 .ssh
[vagrant@oelbox ~]$ cd .ssh
[vagrant@oelbox .ssh]$ wget --no-check-certificate -O authorized_keys
--2015-07-18 21:29:16--
Connecting to||:443... connected.
WARNING: certificate common name “” doesn’t match requested host name “”.
HTTP request sent, awaiting response... 200 OK
Length: 409 [text/plain]
Saving to: “authorized_keys”

100%[===========================================================================================================================================================>] 409         --.-K/s   in 0s

2015-07-18 21:29:17 (94.1 MB/s) - “authorized_keys” saved [409/409]

[vagrant@oelbox .ssh]$ chmod 600 authorized_keys

Choose Install Guest Additional CD from Virtual Box menu and check if CDROM it was mounted

Install required packages and add Guest tools
[root@oelbox ~]# yum install kernel-uek-devel-3.8.13-16.2.1.el6uek.x86_64
[root@oelbox ~]# mount /dev/cdrom /mnt/
mount: block device /dev/sr0 is write-protected, mounting read-only
[root@oelbox ~]# /mnt/
Verifying archive integrity... All good.
Uncompressing VirtualBox 4.3.20 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 4.3.20 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox non-DKMS kernel modules       [  OK  ]
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module                   [  OK  ]
Building the shared folder support module                  [  OK  ]
Building the OpenGL support module                         [  OK  ]
Doing non-kernel setup of the Guest Additions              [  OK  ]
Starting the VirtualBox Guest Additions                    [  OK  ]
Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping. 

14. Install packages required for Oracle database and EPEL repository and Ansible. 
If you are using RedHat or Centos you can’t use oracle-rdbms packages. Oracle-ansible playbook, which will be used later will take care about all packages during a first installation.

[root@oelbox ~]# yum install oracle-rdbms-server-11gR2-preinstall.x86_64 oracle-rdbms-server-12cR1-preinstall.x86_64
[root@oelbox ~]# rpm -Uvh
warning: /var/tmp/rpm-tmp.SCcj3K: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Preparing...                ########################################### [100%]
   1:epel-release           ########################################### [100%]
[root@oelbox ~]# yum install ansible

15. Configure sudo for vagrant user - disable requiretty and allow vagrant user to run sudo without password for all commands.
[root@oelbox ~]# visudo
#Defaults    requiretty

16. Shutdown Virtual Machine.

This is end of configuration on the Linux level and this Virtual Machine can be used now as a source of the Vagrant box.


Monday, July 20, 2015

How to avoid boring work

Over the past few years working as an IT consultant, I've learned that having easy access to a robust lab where I can learn or test solutions is critical. But my approach to building a test lab has changed over the years.
These days I prefer not to "build" a lab but to "define" one — it is a better use of my time.
Building requires a long step-by-step process of installing all the necessary components: OS, databases, app servers, one by one based on the documentation. 
Instead, I can define a lab using tools such as Ansible, Chef, Puppet, Oracle Enterprise Manager, on top of tools that manage Virtual Machines like Vagrant or libvirt.

I presented my thoughts during Irish Oracle User Group conference in March 2015 ( How to avoid boring workand now I would like to start a series of blog post about this.

Here is a list of topics I plan to cover in the next few weeks:
  • Creating and managing a Virtual Machine using Vagrant (create a new box, add storage, use KVM or AWS EC2 as providers )
  • Installing and configuring Oracle Database using Ansible ( Thanks to great work of Mikael Sandstr├Âm on his Github Ansible repository )
  • Integration of Delphix "Data as a Service" product with an automated test environment build


Monday, December 22, 2014

Data Guard and Oracle Restart, aka relink always !!!

During my early years with PC I love to play "Leisure Suit Larry" (especially part 1 to 3 which has running on CGA or Hercules graphics card). Author of this games, Al Lowe had a good sense of humor and every time you failed your mission or stuck in a place - there was an pop up on the screen "Al says: save early, save often". After today fight with Oracle I should remember a next saying - "Relink after, relink always".

Let me explain what what happen today.

There used to be old Oracle bug in 11.2g which I described here. Basically Oracle Restart was not aware of role changes and could open a database in wrong mode after role switch. I created a workaround for it but I was really waiting for a patch. During a UKOUG 2014 I was speaking with Oracle Data Guard Product Manager - Larry Carpenter - and I learned that patch is ready. I asked @UweHesse for details and I got my numbers back - patch 15986647 and it is included in latest PSU

After I got this information I was happy - I just applied this PSU last week, so let's test it.

The first run looked OK - after switchover Oracle Restart displayed proper role and start-up option on new primary
2014-12-22 09:02:36.511: [    AGFW][2057]{0:0:44372} Agent received the message: RESOURCE_MODIFY_ATTR[ora.apppre11.db 1 1] ID 4355:617901
2014-12-22 09:02:36.513: [ora.apppre11.db][9207]{0:0:44372} [res_attr_modified] clsn_agent::modify {
2014-12-22 09:02:36.513: [ora.apppre11.db][9207]{0:0:44372} [res_attr_modified] clsn_agent::modify }
2014-12-22 09:02:36.513: [    AGFW][9207]{0:0:44372} Command: res_attr_modified for resource: ora.apppre11.db 1 1 completed with status: SUCCESS
2014-12-22 09:02:36.516: [    AGFW][2057]{0:0:44372} Attribute: ROLE for resource ora.apppre11.db modified to: PRIMARY
2014-12-22 09:02:36.516: [    AGFW][2057]{0:0:44372} Attribute: USR_ORA_OPEN_MODE for resource ora.apppre11.db modified to: open
2014-12-22 09:02:36.516: [    AGFW][2057]{0:0:44372}  config version updated to : 69 for ora.apppre11.db 1 1
2014-12-22 09:02:36.516: [    AGFW][2057]{0:0:44372} Agent sending last reply for: RESOURCE_MODIFY_ATTR[ora.apppre11.db 1 1] ID 4355:617901
2014-12-22 09:02:36.663: [    AGFW][2057]{0:0:44374} Agent received the message: RESOURCE_MODIFY_ATTR[ora.apppre11.apppre_adf.svc 1 1] ID 4355:617914
but only proper role on the new standby.

2014-12-22 09:03:10.420: [    AGFW][2057]{0:0:11369} Agent received the message: RESOURCE_MODIFY_ATTR[ora.apppre21.db 1 1] ID 4355:189787
2014-12-22 09:03:10.423: [ora.apppre21.db][2412]{0:0:11369} [res_attr_modified] clsn_agent::modify {
2014-12-22 09:03:10.424: [ora.apppre21.db][2412]{0:0:11369} [res_attr_modified] clsn_agent::modify }
2014-12-22 09:03:10.424: [    AGFW][2412]{0:0:11369} Command: res_attr_modified for resource: ora.apppre21.db 1 1 completed with status: SUCCESS
2014-12-22 09:03:10.424: [    AGFW][2057]{0:0:11369} Attribute: ROLE for resource ora.apppre21.db modified to: PHYSICAL_STANDBY
2014-12-22 09:03:10.424: [    AGFW][2057]{0:0:11369}  config version updated to : 142 for ora.apppre21.db 1 1
2014-12-22 09:03:10.424: [    AGFW][2057]{0:0:11369} Agent sending last reply for: RESOURCE_MODIFY_ATTR[ora.apppre21.db 1 1] ID 4355:189787
Start up option was still open instead of mount. Hmmm, I was sure that both nodes are same but again I reconfigure Data Guard Broker and Oracle Restart - no change - issue was resolved on the one server only.  Then I decided to double check if I have this PSU installed, and I found out that everything was in order in terms of PSU.
-bash-3.2$ /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch lsinventory
Oracle Interim Patch Installer version
Copyright (c) 2013, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/11.2.0/dbhome_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0/dbhome_1/oraInst.loc
OPatch version    :
OUI version       :
Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2014-12-22_15-08-59PM_1.log

Lsinventory Output file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/lsinv/lsinventory2014-12-22_15-08-59PM.txt

Installed Top-level Products (1):

Oracle Database 11g                                        
There are 1 product(s) installed in this Oracle Home.

Interim patches (3) :

Patch  18235390     : applied on Mon Dec 22 14:54:02 GMT 2014
Unique Patch ID:  18349043
   Created on 4 Dec 2014, 18:50:09 hrs PST8PDT
   Bugs fixed:

Patch  19121549     : applied on Mon Nov 17 14:06:54 GMT 2014
Unique Patch ID:  18060349
Patch description:  "OCW Patch Set Update : (19121549)"
   Created on 7 Oct 2014, 03:38:04 hrs PST8PDT
   Bugs fixed:
     18328800, 18691572, 14525998, 18187697, 18348155, 17516024, 17387214
     17750548, 17617807, 17551223, 14671408, 14207615, 18272135, 18180541
     17292250, 17378618, 17500165, 18875012, 18464784, 17065496, 18848125
     13991403, 17955615, 14693336, 17273020, 17238586, 17089344, 17405605
     17531342, 17155238, 17159489, 18053580, 16543190, 17039197, 16317771
     17947785, 10052729, 16281493, 18346135, 17481314, 18199185, 18399991
     18024089, 18428146, 18352845, 18352846, 17391726, 18414137, 17001914
     17927970, 14378120, 16346413, 17305100, 15832129, 15986647, 16901346
     18068871, 17985714, 18536826, 16206997, 18752378, 16876500, 16429265
     18343490, 18336452, 16613232, 17273003, 19276791, 12928658, 18226143
     17172091, 18229842, 18053631, 16867761, 18231837, 15869775, 17483479
     18729166, 17405302, 15920201, 18709496

Patch  19121551     : applied on Mon Nov 17 14:05:34 GMT 2014
Unique Patch ID:  17971200
Patch description:  "Database Patch Set Update : (19121551)"
   Created on 9 Oct 2014, 13:06:55 hrs PST8PDT
Sub-patch  18522509; "Database Patch Set Update : (18522509)"
Sub-patch  18031668; "Database Patch Set Update : (18031668)"
Sub-patch  17478514; "Database Patch Set Update : (17478514)"
   Bugs fixed:
     16929165, 16220077, 17235750, 17468141, 18191164, 17006183, 16315398
     17501491, 13955826, 17288409, 12905058, 17446237, 17375354, 16992075
     16855292, 17050888, 17546973, 18554871, 17726838, 17614134, 9756271
     18673325, 17227277, 17232014, 13853126, 17545847, 17390160, 18096714
     12747740, 17016369, 17786518, 19271443, 10136473, 16785708, 17311728
     18018515, 16268425, 17610798, 18280813, 17082359, 17783588, 14245531
     18094246, 13866822, 17477958, 16943711, 18673304, 18031668, 19463897
     19463893, 19211724, 13498382, 16450169, 17397545, 17786278, 17767676
     14458214, 19289642, 17622427, 17824637, 17716305, 16399083, 18744139
     14852021, 19727057, 17242746, 17174582, 18277454, 13645875, 14084247
     17551709, 17393683, 17614227, 17705023, 17883081, 16042673, 18996843
     16285691, 17393915, 16228604, 17655634, 17596908, 17600719, 16180763
     17754782, 17323222, 18264060, 17325413, 17343514, 17865671, 16613964
     17811447, 16069901, 17390431, 16494615, 16043574, 17006570, 17027426
     14602788, 17080436, 18673342, 17186905, 17011832, 17394950, 13944971
     17752121, 17284817, 17811456, 17238511, 17239687, 17042658, 14764829
     17602269, 17672719, 17891946, 17205719, 18262334, 16721594, 17071721
     14565184, 17265217, 17389192, 17761775, 16360112, 17982555, 17842825
     19121551, 16837842, 18139690, 17313525, 18203837, 18203838, 18203835
     18436307, 17546761, 17721717, 17344412, 17787259, 16472716, 17346671
     17588480, 13364795, 14657740, 11733603, 17811438, 19466309, 17040527
     17037130, 17088068, 17612828, 18180390, 17449815, 19458377, 19554106
     18973907, 18230522, 19544839, 17811429, 16863422, 17237521, 17951233
     17752995, 16392068, 17437634, 14338435, 13609098, 17332800, 18199537
     17465741, 17441661, 18522509, 18061914, 14133975, 17570240, 16692232
     18247991, 18328509, 16956380, 17587063, 19049453, 16618694, 17586955
     18009564, 14285317, 16542886, 17341326, 17571306, 17036973, 18641419
     16524926, 17297939, 17478145, 17040764, 17299889, 16912439, 15861775
     14054676, 13951456, 17267114, 16850630, 17648596, 14010183, 17296856
     17478514, 16875449, 18681862, 14829250, 17385178, 17443671, 16731148
     16314254, 17165204, 15979965, 19584068, 17381384, 17892268, 16198143


OPatch succeeded.
But on one server I was testing patch for OEM (18235390) to allow it to monitor tablespaces without ORA-1000 errors.Is it possible that my OEM patch add anything special ?
I was thinking about that for a while but I was not sure. So I did simple test - installed this patch on standby server and ... yes - Oracle Restart issue has been fixed. 
Strange, very strange - what this patch did that Data Guard was fixed ? Well it did one important thing - it relinked oracle binaries again.
Lucky enough I got one more pair with latest PSU ready for test.I run test with PSU installed and bug was still there. OK - so let's relink - and it was it

2014-12-22 14:33:40.942: [    AGFW][2057]{0:0:12827} Agent received the message: RESOURCE_MODIFY_ATTR[ora.apppre21.db 1 1] ID 4355:199223
2014-12-22 14:33:40.944: [ora.apppre21.db][9494]{0:0:12827} [res_attr_modified] clsn_agent::modify {
2014-12-22 14:33:40.945: [ora.apppre21.db][9494]{0:0:12827} [res_attr_modified] clsn_agent::modify }
2014-12-22 14:33:40.945: [    AGFW][9494]{0:0:12827} Command: res_attr_modified for resource: ora.apppre21.db 1 1 completed with status: SUCCESS
2014-12-22 14:33:40.946: [    AGFW][2057]{0:0:12827} Attribute: ROLE for resource ora.apppre21.db modified to: PHYSICAL_STANDBY
2014-12-22 14:33:40.946: [    AGFW][2057]{0:0:12827} Attribute: USR_ORA_OPEN_MODE for resource ora.apppre21.db modified to: mount
2014-12-22 14:33:40.946: [    AGFW][2057]{0:0:12827}  config version updated to : 153 for ora.apppre21.db 1 1
2014-12-22 14:33:40.946: [    AGFW][2057]{0:0:12827} Agent sending last reply for: RESOURCE_MODIFY_ATTR[ora.apppre21.db 1 1] ID 4355:199223
This is quite strange and a little bit scary. I have installed all PSU using opatch auto from Grid Infrastructure Home and there was no errors but relinking Oracle Home actually fix a problem which was included in the patch. 
So remember "Relink after (patch), relink always"

Sunday, August 24, 2014

AWR Warehouse

I just noticed last week that there is a new patch for Enterprise Manager and it is enabling AWR Warehouse feature. There is a note ID 1901202.1 which describe bundle patch for OEM 12c release 4.

Today I had a chance to install it in my lab and now I can start testing new OEM feature.
There is some documentation here and on Kellyn's blog.

It is not configured so first task is to configure AWR Warehouse repository. In my case I will use same database which is used for OEM repository.

Retention period and staging area for snapshot files has to be configured as well.

 After these two steps AWR Warehouse configuration job is started and when it will be finished AWR Warehouse will be ready to use.

When repository is ready we can start adding databases which will be a source of AWR data.

To add a new database to warehouse it has be already configured in OEM and has a default credentials.

If all conditions are met database has been successfully added.

Now it's time to play with these new feature and see what we can achieve using it.