Monday, March 28, 2016

virtualbox only showing 32 bits options

I received  my new laptop from my work this week. In general I tend to be not that happy with receive a new laptop from work because it takes some time from your day to get everything back working again. However, this time I was more disappointed than normal as it turned out that I was not able to run 64 bit guests on my laptop and only 32 bits options where available.

After some checking I found out that my OS was a 64 bit OS and everything should work as far as I could see. However, only 32 bits options where available. As it turns out Windows 7 in combination with virtualbox is not allowing you to run 64 bit guests when certain virtualization is not enabled in the bios of your machine.

After turning on "Intel Virtualization Technology" and "Intel VT-d feature" virtualbox again allowed for running 64 bit guests.

Just a small reminder for everyone who runs into this issue. In case you have this enabled and it is not working, make sure that you disable Hyper-V on windows.

For more background information on this you can refer to ticket 12350 on the virtualbox website. 

Sunday, March 06, 2016

Oracle Linux - Build a Private YUM Server

Most people working with Oracle Linux will have a way of updating systems by using YUM. When using Oracle Linux as a personal workstation or just a private test server it is perfectly good to use the public YUM server from Oracle.

In cases where you have a secured environment running production servers you most likely do not want to use a connection to a external system to get your updates. You would like to have a local copy of the YUM server. In those cases you can create a satellite YUM server. This will make sure that you always have an updated repository locally which is in sync with the public yum server from Oracle.

However, a second reason can exists to have a local YUM server. In cases where you develop your own RPM's and want to make them available to your Oracle Linux machines it is good practice to run your own local YUM server.

Building a local YUM server is quite easy and not a hard task, making the short investment to ensure you have a your own local YUM server for your self developed RPM's or for packages from other vendors needed in your landscape makes much sense.

The below diagram shows on a high level on how your deployment can look like, not including all firewall components and network components you should use to ensure a correct network zone model for security.

Create YUM Repository
Creating a YUM repository takes a number of steps. First of all you need to have a location where you will store the RPM's and the associated repository meta-data. In our case we know we want to make the YUM repository available via HTTP (using NGINX) at a later moment so we create a location like shown below for our company repository.

  mkdir /var/www/repos/companyrepo

The next step will be to ensure that you copy all the RPM's you want to include in your company repository to this location. As soon as they are moved to this location you will have to make this into a real repository. For this you will need some tooling installed on your server. You can do so by installing the below RPM's

  rpm -ivh deltarpm-3.6-3.el7.x86_64.rpm
  rpm -ivh python-deltarpm-3.6-3.el7.x86_64.rpm
  rpm -ivh createrepo-0.9.9-25.el7_2.noarch.rpm

As soon as you have the required tooling installed you can create a repository by executing the following commands:


That's it? yes, that is it. Nothing more to do. It will go through your RPM's stored and will create the needed information. You will find a new director named repodata which contains all the data needed for remote YUM clients to connects

Configure NGINX
Having your RPM's and the YUM metadata in the newly created repodata is great. However, what you want is to ensure your clients (servers) can connect to the YUM repository (in the diagram located on To enable clienst to connect you will have to ensure that the location where you store this (in this example /var/www/repos/companyrepo) is available via HTTP.

As we do not need a heavy weight HTTP server we can use for example NGINX. To install NGINX on Oracle Linux you can refer to this blogpost which provide the needed guidance.

As soon as you have NGINX running you need to ensure that it will point to /var/www/repos/companyrepo . As an example you will need to undertake the following steps to complete the configuration of NGINX.

1) Create a file named companyrepo.conf in /etc/nginx/conf.d
  touch /etc/nginx/conf.d/companyrepo.conf

2) Edit the file with VI and ensure you have the below information in the file:
  server {
      listen       80;
      server_name  localhost;

      location / {
          root   /var/www/repos/companyrepo;
          index  index.html index.htm;

      error_page   500 502 503 504  /50x.html;
      location = /50x.html {
          root   /usr/share/nginx/html;

3) Test if you can access this location on with a standard browser.

Configure Local Servers
As we now have a local YUM server running on and made it available via HTTP we can now configure the clients (servers) to connect to the local YUM repository and make use of it.

Make sure you have the below configuration in a .repo file in /etc/yum.repos.d . You can have other files in this location as well if required however the below content in a .repo file (for example companyyum.repo) will ensure you can connect to the local company YUM repository and use YUM for installing your own RPM's or RPM's from other vendors.

   name=Local company YUM repository

Update YUM Repository
In case you need to update your local yum server and want to add RPM's to it you do not have to go through the enture createrepo procedure. This can, in case you have a very large set of RPM's, take quite some time. In case you only want to add the new files to the YUM meta-data and make them available to users you can issue the below command instead.

  createrepo --update .

Now your server has the new RPM's availabel for YUM users to connect. In case you directly issue a yum command on one of your clients and it is unable to find the new package it might very well be that your client is having a cache of the repository data locally. This will not contain the new package. To make sure your client is doing a fresh grab of the repository data you will have to enforce the expiration of the local cache by issuing the below command on the client:

  yum clean expire-cache

The time the cache is kept is configured in /etc/yum.conf and by default it reads keepcache = 1 . This means that you might not run into this issue on every client. However, if your client already did an interaction with the YUM server that day it might have a cache that is not expired yet and might not find the package due to that reason.