Wednesday, June 22, 2016

Repair YUM on Oracle Linux

Whenever playing with Oracle Linux and trying out things on test systems you will break stuff at one point in time. As long as you except the fact that stuff might break when you try out new things this is not an issue. As long as you understand that production systems are not play systems there is also no issue. I recently hit an issue when I was trying to find ways to do an upgrade of Python. Even though all looked fine in the beginning I found out that it actually killed the way how some python scripts react. And more specifically how yum (a python script) reacted.

When trying to install some additional packages for another project by using yum the error message I received stated the below:

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named yum

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.6 (default, Jun 14 2016, 09:18:35)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]

If you cannot solve this problem yourself, please go to
the yum faq at:

As it turns out the, yum is not able to work with the newer version of python that has become my standard python version (which I needed for Tensorflow). The issue can be resolved by calling the previous version explicitly.

If you check the content of /usr/bin/yum this will be as shown below:

import sys
    import yum
except ImportError:
    print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:


Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:

If you cannot solve this problem yourself, please go to
the yum faq at:

""" % (sys.exc_value, sys.version)

sys.path.insert(0, '/usr/share/yum-cli')
    import yummain
    yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
    print >> sys.stderr, "\n\nExiting on user cancel."

As can be seen, the default version is called, by changing this to the previous version (do note my other blogpost on Python) you can repair yum again. After changing the first line to the one below yum worked again without any issue.


Tuesday, June 14, 2016

Upgrade Python on Oracle Linux

When deploying (currently) an Oracle Linux instance on the Oracle public compute cloud you will most likely get python version 2.6.6. The deployment version of Oracle Linux will provide you with Oracle Linux 6.6 configured in the manner as Oracle has prepared it for cloud deployment. Which is not that different from what you might install yourself.

The below screenshot from the Oracle compute cloud shows the version we will be using in this example.

As stated, this version will be shipping Python 2.6.6. In some cases you do want to upgrade your python version. We will upgrade Python in this example from Python 2.6.6 to a Python 2.7.6 version. Python is also shipping in a Python 3.x.x version, however, some changes to Python have been made which might render existing python code written under Python 2.x.x. unusable. For this reason we will stick with Python 2.7.6 while also perserving the Python 2.6.6 version on the system.

In esscence this is not making it a upgrade which will replace the old version, it is rather a Python 2.7.6 installation where we make Python 2.7.6 the default version instead of the Python 2.6.6 version.

Preparing the system
We will be compiling Python so we have to ensure we have the right development and build tooling installed. This can be done with yum by doing a group install and a install of a number of other packages as shown below.

yum groupinstall "Development tools"

yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel

This ensures your Linux environment will have all the needed packages to do the compilation of Python 2.7.6

Downloading and compiling
We will be downloading the source code and compiling it into a workable version. A couple of things to keep in mind during the compilation are that we "need" to extent the configure command with the below to ensure the path in compiled into the executable during compilation.  LDFLAGS="-Wl,-rpath /usr/local/lib"

The following steps are needed to download, configure and build Python 2.7.6 into you systems:

cd /tmp
tar xf Python-2.7.6.tar.xz
cd Python-2.7.6
./configure --prefix=/usr/local --enable-unicode=ucs4 --enable-shared LDFLAGS="-Wl,-rpath /usr/local/lib"
make altinstall

With this done you should now have Python 2.7.6 installed on your system

Making Python 2.7.6 default
As we have installed Python 2.7.6 installed next to Python 2.6.6 the default version is still 2.6.6. you can check it in the same fashion as shown below

[root@tensor-0 bin]# which python
[root@tensor-0 bin]# python --version
Python 2.6.6
[root@tensor-0 bin]# 

As you can see python is found in /usr/bin/ and is currently version 2.6.6 while we would like Python 2.7.6 to be the default version.

You can achieve this by doing the following:
  • Rename /usr/bin/python to /usr/bin/python to /usr/bin/python2.6
  • softlink /usr/local/bin/python2.7 to /usr/bin/python (as shown below)

ln -s /usr/local/bin/python2.7 /usr/bin/python

This should ensure that you now have Python version 2.7.6 as the prime version when calling it. You can again check this by doing a python --version command which now should show 2.7.6 instead of 2.6.6

Resolved - Linux - unprotected private key file

When connecting to other systems using SSH in a key based manner you might have situations sometimes where you move your privtae key from one machine to another. For example when you have a new workstation you want your keys on this machine as they match the keys on other systems and the combiantion is needed to make the connection.

When you simply place them on your new machine without any other actions and connect to a remote SSH deamon it can happen that you will see the below message. (might differ slightly).

Permissions 0744 for '/home/jlo/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/jlo/.ssh/id_rsa

This is your local machine telling you that your key is not having the appropriate permissions. Or in other words, the permissions on the key are to open and not secure enought. To resolve this you will have to execute a chmod. In our example, a chmod on these two files:

chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/

This should resolve the issue for you and you should be able to connect via SSH in a key based manner without any issues. 

Monday, June 13, 2016

How to Manage and Monitor the Oracle ZFS Storage Appliance

Oracle storage solutions in the form of ZFS appliances are widely used in oracle focused and none-oracle focused IT footprints. This is for good reason as Oracle provides a good storage solution with the ZFS storage appliance range. I already posted a number of blogposts on ZFS, including on how to analyse the ZFS storage appliance and on how to use the ZFS storage appliance simulator.

The Oracle ZFS storage appliance simulator is a Oracle VirtualBox appliance which can be used to use for testing and learning purposes.

To add to the already mentioned posts is now this post, providing you the below video on how to manage and monitor the Oracle ZFS storage appliance which might provide you additional information when exploring the options of ZFS appliances.

Monday, June 06, 2016

Oracle DBaaS Cloud Listener

When developing a private database cloud to provide Database as a Service (DBaaS) solutions to internal customers this will require a different way of looking at common concepts opposed to more static environments. In the attached paper the concept of the Cloud Listener is explained. The Cloud Listener concept is a concept based upon the Oracle Remote listener concept which is more commonly used in environments.

Using the concept of the Oracle Remote Listener to have user connecting to the database is an ideal concept to enrich the experience of a private cloud serving databases as a service to internal users.

This concept, as outlined in the paper, is a tested and proven solution which has been implemented by the authors at customers who use large numbers of databases in a highly agile environment. The environment where this has been used are commonly full Oracle based environments where the overall IT footprint consists out of private cloud deployments based upon Oracle Linux, Oracle VM and Oracle Enterprise manger (including all self service options available within OEM).

The above whitepaper is written by Peter Lengkeek and Johan Louwers.

Friday, June 03, 2016

Oracle with Docker and Openstack

Oracle is a supporter of both Docker and and Openstack. They provide a solution using Docker and Openstack in combination with Oracle Linux and Oracle Solaris. To understand more of the benefits of both Docker and Openstack please refer to the post I recently wrote on the website which will outline this in more detail.

This post will give you some insights into why the combination of both Docker and Openstack is a solution enterprises want to look into when developing there next IT footprint for the future.