Monday, April 27, 2015

Oracle Linux 6.5 on Hyper-V - kernel: end_request: I/O error, dev fd0, sector 0

I was receiving the following error sporadically on freshly built Oracle Linux 6.5 64-bit (UEK) running atop a Hyper-V cluster:

kernel: end_request: I/O error, dev fd0, sector 0

Removing the floppy drive from Hyper-V isn't an option, and these systems are provisioned largely via automation, so I needed a way to disable the floppy driver via a boot option or similar.

I bit of searching uncovered a few ways to blacklist the module but nothing seemed to work. Eventually, adding the following to the grub boot options worked a treat!


iostat reports no fd0 device anymore, and the pesky I/O errors are finally gone.

Thursday, April 23, 2015

Installing Puppet (open-source) and Puppet Dashboard on Oracle Linux 6.5 (UEK) 64-bit

Well, I had to provision a replacement Ops Management server recently, which meant configuring a new instance of Puppet, Puppet Dashboard, and getting the Puppet Clients to check in to the new server. I thought it would be a good time to document the process. The following is performed on an Oracle Linux 6.5 64-bit machine running the Unbreakable kernel.

Installing Puppet Master

Ensure we can get out over a corporate proxy:


Install Puppet Master:
# rpm -ivh
# yum install puppet-server

Turn the service on and ensure it turns on the next time the system boots:
# chkconfig puppetmaster on
# service puppetmaster start

Installing Puppet Dashboard

Install packages required:
# yum install mysql mysql-server puppet-dashboard

Configure MYSQl and turn on:
# vi /etc/my.cnf (add the following)
max_allowed_packet = 32M

# chkconfig mysqld on; service mysqld start

# vi /usr/share/puppet-dashboard/config/settings.yml
(change the following)
time_zone: 'YOUR_TIME_ZONE'


Note: run ‘cd /usr/share/puppet-dashboard; sudo -u puppet-dashboard RAILS_ENV=production rake time:zones:local' to find your timezones

Create and configure the dashboard DB, user and permissions:
# mysql
mysql> CREATE DATABASE dashboard CHARACTER SET utf8;
mysql> CREATE USER 'dashboard'@'localhost' IDENTIFIED BY 'my_password';
mysql> GRANT ALL PRIVILEGES ON dashboard.* TO 'dashboard'@'localhost';
mysql> quit

# cd ~puppet-dashboard; rake gems:refresh_specs
# vi /usr/share/puppet-dashboard/config/database.yml

(change production database from dashboard_production to database. Also add the password of my_password)

# cd ~puppet-dashboard && rake RAILS_ENV=production db:migrate

Configure Puppet Master:
# cp /etc/puppet/puppet.conf /etc/puppet/puppet.conf.orig
# service puppetmaster stop

# vi /etc/puppet/puppet.conf

(it should look like this..)

    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet

    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet

    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

    # Puppet Module Path
    modulepath = /etc/puppet/modules:/usr/share/puppet/modules

    # Import Custom Facts
    pluginsync = true

    # The file in which puppetd stores a list of the classes
    # associated with the retrieved configuratiion.  Can be loaded in
    # the separate ``puppet`` executable using the ``--loadclasses``
    # option.
    # The default value is '$confdir/classes.txt'.
    classfile = $vardir/classes.txt

    # Where puppetd caches the local configuration.  An
    # extension indicating the cache format is added automatically.
    # The default value is '$confdir/localconfig'.
    localconfig = $vardir/localconfig

    # puppet certificate name

    # Set autosign on
    autosign = true

    reports = puppet_dashboard
    reportdir = /var/lib/puppet/reports
    reporturl = http://puppet.YOUR_DOMAIN:3000/reports/upload

    node_terminus  = exec
    external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=http://localhost:3000 /usr/share/puppet-dashboard/bin/external_node


File configuration and permission changes:
# cp /usr/share/puppet-dashboard/ext/puppet/puppet_dashboard.rb /usr/lib/ruby/site_ruby/1.8/puppet/reports/
# mkdir /var/lib/puppet/reports
# chown puppet-dashboard:puppet-dashboard reports; chmod 766 reports
# touch /usr/share/puppet-dashboard/log/production.log
# chmod 666 /usr/share/puppet-dashboard/log/production.log


Turn it all on and ensure it starts on boot:
# chkconfig puppet-dashboard on; service puppet-dashboard start
# chkconfig puppet-dashboard-workers on ; service puppet-dashboard-workers start

Check it worked:
Browse to http://puppet:3000

Friday, April 10, 2015

Your security settings have blocked an application signed with an expired or not-yet-valid certificate from running

Who doesn't love Java, right?

To fix this, you need to add the URL of the site you're trying to access to the trusted list of sites within Java (assuming you trust the source as safe of course

To do this, perform the following:

Open the "Configure Java" window clicking Start and typing Configure java, or execute the following binary - "C:\Program Files (x86)\Java\jre7\bin\javacpl.exe"

Click the Security Tab, and then the Edit Site List button towards the bottom. Important things to remember, the URL format doesn't support wildcards (boo), and you must include the port if it's not default (80).

Example: I'm trying to access I would add to the access list and refresh the browser.

More info on URL syntax:

Thursday, April 2, 2015

Oracle Linux Operational Plan fails immediatly in Ops Center

If you launch an Operational Plan from Ops Center, against an Oracle Linux server and it fails immediately with very limited information in the job are not alone, nor are you doing anything wrong. It's a bug in Ops Center, specifically with the 12.2 agent.

If you plan on moving to Ops Center 12.2.2, it will fix the issue (i can confirm). Otherwise, log an SR with Oracle and they can spin you up an IDR to replace your agent.

If you need to reference a bug ID to make things happen a little quicker, try the following...

Fixed in 12.2.2.

Excerpts from cacao :
Caused by: java.lang.ClassNotFoundException: Cannot find class com.sun.scn.jobmanager.common.api.Target in module public_com.sun.scn.agentfacadenonvc

##### Bug says :
This issue has been introduced in Diamond. The packing of agent packages has changed which is causing this issue.
This bug can be seen on Linux boxes as well. Operational profiles seem to work flawlessly in 12.1.4. This issue has been introduced in 12.2 somehow.