Oracle Linux - Install beanstalkd

When you have a requirement for the installation of beanstalkd you might find out that beanstalkd is not available in the mainstream repository for Oracle Linux.

Beanstalkd is a big to-do list for your distributed application. If there is a unit of work that you want to defer to later (say, sending an email, pushing some data to a slow external service, pulling data from a slow external service, generating high-quality image thumbnails) you put a description of that work, a “job”, into beanstalkd. Some processes (such as web request handlers), “producers”, put jobs into the queue. Other processes, “workers”, take jobs out of the queue and run them.

Looking at the beanstalkd website you will also learn that no RPM is available as such for a quick download and installation. This means that you will have to download the sourcecode and compile it yourself. Below you can find a quick instruction on how to download and compile beanstalkd on a Oracle Linux system. This will most likely not be that different from how you should do this on, for example, a Red Hat system.

First, we need to make sure we have a location to store the source. We will create a temporary directory for this in /tmp

  mkdir /tmp/build_beanstalkd

Download (clone) the sourcecode from github by executing a git clone command and make sure we put it in the temp directory we just created

  git clone git://github.com/kr/beanstalkd.git /tmp/build_beanstalkd/

We now have the sourcecode so we can go to the directory and compile and install beanstalkd

  cd /tmp/build_beanstalkd/
  make
  make install

By now you should have a compiled and installed version of beanstalkd. It is good practice to ensure you cleanup after yourself so we will remove all the " junk"  we just created.

  rm -rf /tmp/build_beanstalkd/

Oracle Linux and scaleable microservice architecture based applications

For a long time the answer to the question how to handle the increase of transactions on a system was vertical scaling. Simply putting in more memory or buying new servers with more processing power. This answer was mainly driven by the fact that most applications have been build based upon a monolithic architecture principle.

In a monolithic architecture principle applications are developed as one single application where all the components (libraries / functions / procedures) would live on a single server and cannot be separated on different servers. In some cases these applications are developed in a way that two of those instances can work together in a clustered manner. However, in many cases the primary way of deploying them is to deploy them on a single server. If it turns out that the use of the application grows and due to this the application gets slower the common answer was, add more compute resources. Adding resources to a server to cope with the growth in demand for compute power is seen as vertical scaling.

Databases, Oracle databases, have adopted the model of horizontal scaling already for some time by using Oracle RAC. When the demand for more compute power grows additional nodes can be added to the RAC cluster. Adding additional nodes, rather than putting more compute power in a single node, is referred to as vertical scaling.

Also in the area of application servers and web servers the vertical scaling model is not something new. Creating a cluster of, for example, Weblogic application servers and loadbalance the load over the members of this cluster is something that already has been done for quite some time.

However, even though Weblogic clustering and Oracle RAC clustered databases are available it is often seen that the foundation of an architecture is not taking into account the vertical scaling model. When you intend to build an application that will make optimal use of vertical scaling you will have to ensure that you incorporate this directly in your architecture. It is good practice to ensure that your application (landscape) will be able to scale vertically even in cases where you do not see the direct use. This is to ensure that if you ever need to scale in the future you do not have to redesign the application from scratch or recode large parts of it.

One example of an architecture principle that will provide you an optimal vertical scaling model is the use of microservices. microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.

Commonly microservices will communicate with each other by using the HTTP protocol, calling (REST-)API’s via HTTP has the advantage you can make use of all the scaling and load balancing options that are commonly available and are already proven technology for years for deploying large web enabled applications.

monolithic application design
By implementing microservices you will avoid building an application based upon a monolithic application design as shown in the below diagram.

Some of the characteristics of an application build based upon a monolithic application design are:

• Application has single code base with multiple modules 
• Large internal dependencies between components and functions
• Components invoke one another via language-level method or function calls
• In general difficult to scale up and down when the situation demands this
• Poor resilience towards component failure, small disturbances often result if complete application unavailability 
• Complex to maintain and difficult to change or integrate with new systems
• Poor re-use of developed functions and components outside of the application
• Commonly depending primarily on vertical scaling of the hardware and not capable of handling horizontal scaling
• Serial development process, takes in general longer to develop.

Microservice application design 
Microservices allow you to build multiple smaller components, capable of running all on one or multiple dedicated machines instead of running the entire application on one single server that cannot be scaled easily. An example of the same application as above, however build upon a microservice architecture, is shown in the below diagram:

Some of the characteristics of building an application based upon a microservice architecture principle are:

• Application is broken down in multiple (micro)services, each having their own code base / programming language
• Components are loosely coupled and communicate based upon API’s and HTTP calls with each other 
• Easy to scale up and down, both vertical as well as horizontal. Each service can run on one, or multiple machines
• Highly resilient towards component failure due to the distributed system principles and the use of multiple small machines. 
• Ease of changing components and integrate with new functions.
• Provides an easy way of function re-use outside of the original application realm.
• Parallel development process, takes in general less time to develop.

Implementing this model provides both advantages in scaling as well as in ensuring your application is resilient against component failure. In the below diagram you can see that some components are scaled to a four node implementation and have presence in two datacenters. This provides both benefits on load balancing as well as improved resilience

Building a node
A node, when used in a microservice architecture will be a machine or virtual machine running one or more microservices. In general this is Linux machine running an application capable of providing an API. One way of building node’s and micorservices is making use of Flask, Flask is a micro web application framework written in Python and based on the Werkzeug toolkit and Jinja2 template engine. It is BSD licensed.

Flask is called a micro framework because it does not presume or force a developer to use a particular tool or library. It has no database abstraction layer, form validation, or any other components where pre-existing third-party libraries provide common functions. However, Flask supports extensions that can add application features as if they were implemented in Flask itself. Extensions exist for object-relational mappers, form validation, upload handling, various open authentication technologies and several common framework related tools. Flask is ideally suited to build microservices on.

In the below diagram we show a node build based upon Flask in combination with NGINX,  NGINX is a free, open-source, high-performance HTTP server and reverse proxy and running both Flask as well as NGINX on an Oracle Linux operating system. In this example we have selected specifically Oracle Linux as microservice nodes are commonly used in deployments that demand high availability, extreme performance and extreme scaling. Oracle Linux can provide this in combination with Flask and NGINX.

Making it virtual
As one of the advantages of microservices is that it can scale easily it is commonly a good practice to ensure that your nodes are based upon a virtualization strategy. As we use Oracle Linux in our example it also makes sense to use Oracle VM as a virtualization layer. When needed a new node with the associated microservice can be created and can be added to the loadbalancing.

When monitoring your entire footprint with Oracle Enterprise Manager you can create a solution in which Oracle VM automatically creates new nodes for you when performance drops due to an increase in the number of requests. Oracle Enterprise Manager will then be able to scale down again as soon the number of requests goes down. By implementing such a self scaling and self healing solution you are assured of a always performing and always available solution to your users. This will require good thought on what kind of hardware to use; in this case it would be a good solution to use for example the Oracle Private Cloud Appliance. The Oracle Private Cloud Appliance is an engineered system, developed by Oracle, specifically to run elastic and changing landscapes based upon Oracle Linux and Oracle VM. 

Oracle Database Security

It might be interesting to know that the estimated value of lost business every year due to cybercrime is around a trillion dollars. Even though IT departments have been trying to ensure their systems are safe and secure and even though spending on IT security budget has doubled in the past couple of years we still see a lot of data breaches over and over again.

In the past year some notable data breaches have occurred and made the news. It is estimated that the know breaches are only a fraction of the real number of breaches in security and leakage of confidential data.

As it currently stands, companies do focus a lot on the external perimeter and defend this quite well. Having security in the lower levels, the core, of a IT footprint is however commonly not implemented. Ensuring you secure the main goal of many attacks is often not done. Oracle provides an extensive set of solutions and products which support companies to secure their database. In a recent blogpost on capgemini.com I go into the details on how the Oracle Maximum Availability Architecture can be used to secure data where it should be secured, namely, where it is created, accessed and stored; the database.

Capgemini technology vision for Oracle Database Security from Johan Louwers

Also the above deck is providing an insight into the options to secure your Oracle database in a more advanced manner to help you protect the data it holds and prevent data breaches. 

Creating video content - keep it short

For some strange reason I have agreed with a couple of people to think about how we could create content in the form of YouTube video’s. seeing this as an addition to the blogging I agreed that it would be nice to not only create content in the form of posts on my personal blog and the company blog as well as slidedecks on slideshare, however, start adding also video content to this mix.

In all honesty I have done some video content previously for internal and external use and I have to admit that I do not always feel comfortable with it. Looking back at some of the video files I can say that I feel I am not a video type. Having stated that, it turns out a lot of people experience the same feelings and emotions while watching themselves on video. A mix of awkward self-consciousness and vicarious embarrassment with the person you see on the video and realizing you are the person on the video. As it turns out, a lot of people are experiencing this and feel uncomfortable watching themselves on video including a long list of prominent TV and film personalities. Meaning, I am not alone in this apparently.

However, having made the promise to support and engage in the creation of a couple of video messages, the question came to me on how long a video should be. The initial thought was that a video, on a pure technical subject, should be around 20 till 30 minutes. A 20 till 30 minute video is considered a long video, unless you are Google TechTalk or TED, this might be a bit long to keep the audience engaged until the end of the video.

Based upon some research done by thenextweb it turns out that the length of the video is really important. Almost regardless of the type of content short video's keep people engaged. A short video is more likely to be watched in full. The below diagram from thenextweb shows the percentage of people that watch the full video in combination with the length of the video. 

As you can see, a rapid decline in the average percentage of the full length video viewed is dropping with the length of the video. This means a couple of things; (A) if you want to state something important in your video you should do this directly at the beginning and (B) if you want to ensure people watch the full length of the video (or a large part of it) you have to keep it short. 

Depending on the research you are reading the ideal length of a online video changes slightly. based upon what ADWeek states about this, a youtube video should be around 3 minutes, if you do a TED talk the ideal length is 18 minutes. 

Other sources state that a YouTube video should be between 0 and 10 minutes. All in all, the general consensus between all research is that a video should be short. In fact, as short as possible and you should avoid long video content. Avoid it, avoid long video content because people will be less attracted to start a long video and people will be less motivated to watch the entire length of a video. It turns out that the concentration span of people while watching online video content is extremely short. 

Given this information, and after some discussion internally, it has been decided that an Ignite way of doing things and building video content might be the best way of creating video content and get the message t the audience. The ignite concept is that presenters get 20 slides, which automatically advance every 15 seconds. The result is a fast and fun presentation which lasts just 5 minutes.More information on Ignite can be found at the ignitetalks.io website. 

Clean removal of Virtualbox on a Mac

Some questions came on how to remove Oracle Virtualbox from a Mac. Not that the person who asked the question was unhappy with Virtualbox, however, due to some issues and some manual fiddling they damaged the installation. Removing software from a Mac is quite easy as an application is (should) be a self contained package. You can remove Virtualbox this way, however to be completely sure it is done in the right way you can also use the official removal tool that is shipped with the installer.

When you run the installer script you will be shown what will be removed, something I personally always like…. knowing what is going to happen.

Welcome to the VirtualBox uninstaller script.

The following files and directories (bundles) will be removed:
    /Users/parmakat/Library/LaunchAgents/org.virtualbox.vboxwebsrv.plist
    /usr/bin/VirtualBox
    /usr/bin/VBoxManage
    /usr/bin/VBoxVRDP
    /usr/bin/VBoxHeadless
    /usr/bin/vboxwebsrv
    /usr/bin/VBoxBalloonCtrl
    /usr/bin/VBoxAutostart
    /Library/StartupItems/VirtualBox/
    /Library/Extensions/VBoxDrv.kext/
    /Library/Extensions/VBoxUSB.kext/
    /Library/Extensions/VBoxNetFlt.kext/
    /Library/Extensions/VBoxNetAdp.kext/
    /Applications/VirtualBox.app/

And the following KEXTs will be unloaded:
    org.virtualbox.kext.VBoxUSB
    org.virtualbox.kext.VBoxDrv

And the traces of following packages will be removed:
    org.virtualbox.pkg.vboxkexts
    org.virtualbox.pkg.vboxstartupitems
    org.virtualbox.pkg.virtualbox
    org.virtualbox.pkg.virtualboxcli

Do you wish to uninstall VirtualBox (Yes/No)?
Yes

The uninstallation processes requires administrative privileges
because some of the installed files cannot be removed by a normal
user. You may be prompted for your password now...

Please enter parmakat's password:
unloading org.virtualbox.kext.VBoxUSB
unloading org.virtualbox.kext.VBoxDrv
Successfully unloaded VirtualBox kernel extensions.
Forgot package 'org.virtualbox.pkg.vboxkexts' on '/'.
Forgot package 'org.virtualbox.pkg.vboxstartupitems' on '/'.
Forgot package 'org.virtualbox.pkg.virtualbox' on '/'.
Forgot package 'org.virtualbox.pkg.virtualboxcli' on '/'.
Done.
logout


[Process completed]

Removing Virtualbox by using the uninstaller script makes sure you will have a more clean environment for a doing the installation again. Also, it has been known that in previous versions of VirtualBox some strange issues have been occurring when you upgraded to the next while using a Mac. Some internal network cards and internal network settings are not always picked up correctly. Meaning, doing a clean removal and a clean installation of Virtualbox on your Max might in some cases be saving you a lot of time.

Oracle Linux - Enforce password complexity

When requesting a new Linux systems it used to be a case where someone with a Linux background would “build” a system based upon the specifications given by the requester and based upon a number of pre-defined settings by the Linux team. With the introduction of virtualization and especially with the introduction of self service models the way new systems are “created” has changed enormously.

A Linux system is now often more considered as a necessity for running applications or databases and less of a tangible “thing”. It is often regarded as a almost stateless asset which can be requested, provisioned and decommissioned with a couple of clicks in a self service portal.  Specially for teams that work on short development projects or in environments that require quickly up and down scaling to be able to handle a workload this makes a lot of sense.

One of the downsides of this however that systems are “created” and managed by people who might be less security aware than your average Linux system operator. This calls for a more strict security management, a more template based implementation of security. And security starts partially with having a good authentication in place, ensuring you have a strong password and surely not a default welcome1 password.

When requesting an Oracle Linux system based upon the Self Service functionality in Oracle Enterprise Manager the requester will have the ability to state a password desired for the root account. It is however good practice to ensure that the user is forced to change the root password on the newly created Oracle Linux system and that this is in line with the standards that are set for this password.

Commonly newly create Oracle Linux systems in a self service manner will be accessed by the requester seconds after they received the automated message that the system is available. Commonly the requester will login via a SSH session and provide the password the requester has provided during the request phase. (This is, if you allow root to login as SSH and if you allow password based authentication).

A good practice is to run a post-installation script on every newly created machine to change any number of settings you like. This post-installation / first boot script can contain the required actions to enforce a password reset on first login an implement the enforcement of a password complexity policy. As an example of how to script this you can have a look at the below snippet of a wider post-installation / first boot script. You can also find this snippet at Github.

#!/bin/bash

# function used to enfore root to reset password on next login.
 function forceRootPwd {
    logger "Setting enforced root password change"
    chage -d 0 root
 }



# function used to ensure the password policy is set
 function forcePolicy {
    logger "setting the password policy"
    echo "password    required    pam_pwquality.so retry=3" >> /etc/pam.d/passwd
    echo "minlen = 8" >> /etc/security/pwquality.conf
    echo "minclass = 4" >> /etc/security/pwquality.conf
    echo "maxsequence = 3" >> /etc/security/pwquality.conf
    echo "maxrepeat = 3" >> /etc/security/pwquality.conf
 }



# call the forceRootPwd function
 forceRootPwd
 forcePolicy

As you can see the script enforces that root will have to reset the password at the next login by executing a chage command against the root account.

Next we will push a number of settings to both /etc/pam.d/passwd as well as /etc/security/pwquality.conf to enforce the quality of a password. As you can see, in the example we do set minlen, minclass, maxsequence and maxrepeat. However you are able to do more specific settings in /etc/security/pwquality.conf , the settings you can set are listed below:

Difok
Number of characters in the new password that must not be present in the old password.

minlen
Minimum acceptable size for the new password (plus one if credits are not disabled which is the default)

dcredit
The maximum credit for having digits in the new password. If less than 0 it is the minimum number of digits in the new password.

ucredit
The maximum credit for having uppercase characters in the new password. If less than 0 it is the minimum number of uppercase characters in the new password.

lcredit
The maximum credit for having lowercase characters in the new password. If less than 0 it is the minimum number of lowercase characters in the new password.

ocredit
The maximum credit for having other characters in the new password. If less than 0 it is the minimum number of other characters in the new password.

minclass
The minimum number of required classes of characters for the new password (digits, uppercase, lowercase, others).

maxrepeat
The maximum number of allowed consecutive same characters in the new password. The check is disabled if the value is 0.

maxclassrepeat
The maximum number of allowed consecutive characters of the same class in the new password. The check is disabled if the value is 0.

gecoscheck
Whether to check for the words from the passwd entry GECOS string of the user.The check is enabled if the value is not 0.

dictpath
Path to the cracklib dictionaries. Default is to use the cracklib default.

IOT infrastructure with Oracle Linux and Mosquitto

MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimize network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.

We see that a large number of IOT and intelligent sensor manufacturers are making use of MQTT to send information from the edge of the network to a centralized location within an infrastructure. For example, sensors are sending out readings using MQTT to a centralized broker, a number of other services have subscribed to the broker to receive readings (payloads) for one or more topics. When building an IOT infrastructure based upon MQTT the role of the message broker is vital. Understanding of the MQTT protocol is also vital for making the correct decisions.

The above architecture blueprint shows on how you can position a MQTT broker in your landscape. The implementation is done based upon the Mosquitto an Open Source MQTT v3.1/v3.1.1 Broker which we deploy on an Oracle Linux 7.1 distribution. The decision for Oracle Linux is driven due to the fact that it is a stable enterprise grade Linux distribution and due to the fact that we do interact a lot with other products from Oracle in this example. Having a lot of Oracle products (which is not necessary) in this landscape gives you the ability to monitor and manage the entire landscape with Oracle Enterprise Manager. Oracle Enterprise manager can play the role as central monitoring solution over all components, for example the Oracle Big Data Appliance as well as the Oracle Exadata database machine and the other Oracle components. And in the same single monitoring solution the Oracle Linux Mosquitto server is integrated. This provides an easy way of maintaining all components without the need to develop custom scripting and lowers the overall TCO and improves the ROI.

When deploying a solution which is, or will/might become a important part of your business, it is advisable to ensure you select enterprise grade components. Selecting Oracle Linux in combination with Oracle Enterprise Manager for monitoring and possible other Oracle hardware and software components is a good practice.

Positioning Mosquitto
Mosquitto is an open source (BSD licensed) message broker that implements the MQ Telemetry Transport protocol versions 3.1 and 3.1.1. MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for "machine to machine" messaging such as with low power sensors or mobile devices such as phones, sensors, embedded computers or microcontrollers. In essence the components that will form a large part of the internet of things (IOT) are making use of the MQTT protocol and Mosquitto is a vital part as the broker.

Understanding the MQTT protocol
The MQTT protocol is based upon a publish and subscribe model. Within this model messages are published to a broker (in our case Mosquitto), subscribers receive messages with a topic they have subscribed to. A “topic” is an important and central piece within the MQTT protocol, a topic can be seen as the descriptor of a message payload.
For example, if your message payload contains the temperature coming from a sensor you want to ensure everybody knows what it is, where it is coming from, etc etc. As an example, if you have an office building where every room contains temperature sensor your “topic” could be: /building01/floor04/room25/tempsensor if you subscribe to this topic as a subscriber the broker will send you all the message payload for this topic.

However, unless this is your specific office space, it is not very useful, you might want for example, want to have all temperature readings of the fourth floor, in this case you can subscribe on the topic /building01/floor04/#/tempsensor by using a wildcard. Adding in every room another type of sensor, you can reuse the topic setup and replace for those sensors tempsensor with humsensors. This enables you to subscribe, for example, to all sensors on the fourth floor by using /building01/floor04/#/#

Understanding topics is vital and critical to be able to build architect a correct topic model which can be used in the optimal way and can be easily extend. If the topic architecture is created in a suboptimal way it will be an enourmous task (depending on the number of sensors) to correct this at a later stage. Taking the correct amount of time to develop a topic model is worth the investment.

The MQTT protocol has a number of message packets that are form the backbone of the MQTT protocol. Prime messages are:

• Publish
• Message payload send by a publisher to the broker
• Subscribe
• Message from a client (subscriber) to subscribe on a specific topic

• Suback
• Message from the broker as a response (conformation) back on a subscription request
• Unsubscribe
• Message from a client (subscriber) to unsubscribe on a specific topic
• Unsuback
• Message from the broker as a response (conformation) back on a unsubscribe request

Building a Oracle Linux & Mosquitto test server
For reasons of stability and due to the fact that Mosquitto will be used often in enterprise grade deployments we will use Oracle Linux as the Linux distribution of choice.  To be able to install Mosquitto on Oracle Linux (release 7.1) you can do a number of things. You can download the source code and compile it yourself or you can use yum to install everything you need. When you want to go down the easy path and install Mosquitto on Oracle Linux by making use of yum you have to realize that Oracle is not provding a RPM for it, meaning it will not be in the standard yum repository that is provided by Oracle. You can however use a specific centos repository. With the below command you will download the repository file and ensure it will be placed in /etc/yum.repos.d

wget http://download.opensuse.org/repositories/home:/oojah:/mqtt/CentOS_CentOS-7/home:oojah:mqtt.repo -O /etc/yum.repos.d/mqtt.repo

If you now do a check on your repositories you should be able to see the mqtt (Mosquitto) repository and it should be active:

[root@localhost ~]# yum repolist all | grep mqtt
home_oojah_mqtt               mqtt (CentOS_CentOS-7)             enabled:      8
[root@localhost ~]#

If we now want to install Mosquitto we could directly use a yum install, however to be sure that the mqtt repository is available we can first do a quick yum list as shown below:

[root@localhost ~]# yum list mosquitto
Loaded plugins: langpacks
Available Packages
mosquitto.x86_64          1.4.4-2.1     home_oojah_mqtt
[root@localhost ~]#

As can be seen from the example we have a mosquitto.x86_64 version 1.4.4-2.1 available within the home_oojah_mqtt repository. Installing it can now be done with a quick yum install as shown below:

 [root@localhost ~]# yum install mosquitto
Loaded plugins: langpacks
Resolving Dependencies
  Running transaction check
  Package mosquitto.x86_64 0:1.4.4-2.1 will be installed
  Processing Dependency: uuid for package: mosquitto-1.4.4-2.1.x86_64
  Running transaction check
  Package uuid.x86_64 0:1.6.2-26.el7 will be installed
  Finished Dependency Resolution

Dependencies Resolved

======================================================================================================
 Package               Arch               Version                   Repository                   Size
======================================================================================================
Installing:
 mosquitto             x86_64             1.4.4-2.1                 home_oojah_mqtt             102 k
Installing for dependencies:
 uuid                  x86_64             1.6.2-26.el7              ol7_latest                   54 k

Transaction Summary
======================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 156 k
Installed size: 346 k
Is this ok [y/d/N]: y
Downloading packages:
(1/2): uuid-1.6.2-26.el7.x86_64.rpm                                            |  54 kB  00:00:01
warning: /var/cache/yum/x86_64/7Server/home_oojah_mqtt/packages/mosquitto-1.4.4-2.1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 49e1d0b1: NOKEY
Public key for mosquitto-1.4.4-2.1.x86_64.rpm is not installed
(2/2): mosquitto-1.4.4-2.1.x86_64.rpm                                          | 102 kB  00:00:06
------------------------------------------------------------------------------------------------------
Total                                                                  23 kB/s | 156 kB  00:00:06
Retrieving key from http://download.opensuse.org/repositories/home:/oojah:/mqtt/CentOS_CentOS-7//repodata/repomd.xml.key
Importing GPG key 0x49E1D0B1:
 Userid     : "home:oojah OBS Project "
 Fingerprint: bdf4 d371 5b8d c145 d583 46e9 f8c8 d6db 49e1 d0b1
 From       : http://download.opensuse.org/repositories/home:/oojah:/mqtt/CentOS_CentOS-7//repodata/repomd.xml.key
Is this ok [y/N]: y
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : uuid-1.6.2-26.el7.x86_64                                                           1/2
  Installing : mosquitto-1.4.4-2.1.x86_64                                                         2/2
  Verifying  : mosquitto-1.4.4-2.1.x86_64                                                         1/2
  Verifying  : uuid-1.6.2-26.el7.x86_64                                                           2/2

Installed:
  mosquitto.x86_64 0:1.4.4-2.1

Dependency Installed:
  uuid.x86_64 0:1.6.2-26.el7

Complete!
[root@localhost ~]#

After installation of Mosquitto you can check if a service has been defined and check the status by executing a systemctl command, shown below:

[root@localhost ~]# sysctl status mosquitto
sysctl: cannot stat /proc/sys/status: No such file or directory
sysctl: cannot stat /proc/sys/mosquitto: No such file or directory
[root@localhost ~]# systemctl status mosquitto
mosquitto.service - LSB: Mosquitto MQTT broker
   Loaded: loaded (/etc/rc.d/init.d/mosquitto)
   Active: inactive (dead)
[root@localhost ~]#

As you can see, sysctl recognizes Mosquitto however Mosquitto has not been started yet. To start this you can execute systemctl start mosquitto and the next time you do a status lookup you will notice a lot more is running within Oracle Linux:

[root@localhost ~]# systemctl status mosquitto
mosquitto.service - LSB: Mosquitto MQTT broker
   Loaded: loaded (/etc/rc.d/init.d/mosquitto)
   Active: active (running) since Tue 2015-11-03 14:38:45 EST; 5s ago
  Process: 2099 ExecStart=/etc/rc.d/init.d/mosquitto start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mosquitto.service
           ââ2101 /usr/sbin/mosquitto -d -c /etc/mosquitto/mosquitto.conf

Nov 03 14:38:45 localhost.localdomain systemd[1]: Starting LSB: Mosquitto MQTT broker...
Nov 03 14:38:45 localhost.localdomain mosquitto[2099]: [121B blob data]
Nov 03 14:38:45 localhost.localdomain mosquitto[2099]: 1446579525: Config loaded from /etc/mosqui...f.
Nov 03 14:38:45 localhost.localdomain mosquitto[2099]: 1446579525: Opening ipv4 listen socket on ...3.
Nov 03 14:38:45 localhost.localdomain mosquitto[2099]: 1446579525: Opening ipv6 listen socket on ...3.
Nov 03 14:38:45 localhost.localdomain systemd[1]: Started LSB: Mosquitto MQTT broker.
Hint: Some lines were ellipsized, use -l to show in full.
[root@localhost ~]#

In esscence you have a running Mosquitto service on your Oracle Linux server. The downside of this installation is that you do not “really” have the tools to test what is working and to play around with your fresh installation. If you want to test Mosquitto you will also have to install the mosquitto-clients tools by executing a yum install mosquitto-clients. As an example you can now test to the Mosquitto service like shown below where we subscribe to the topic test/mqtt

[root@localhost ~]# mosquitto_sub -d -t test/mqtt
Client mosqsub/2239-localhost. sending CONNECT
Client mosqsub/2239-localhost. received CONNACK
Client mosqsub/2239-localhost. sending SUBSCRIBE (Mid: 1, Topic: test/mqtt, QoS: 0)
Client mosqsub/2239-localhost. received SUBACK

If you want to see the full working of the pub/sub mechanism you can keep the above statement running in a terminal and open a second terminal. The first (above shown) command will act as the subscriber to the topic test/mqtt. In the second we will be pubishing information to Mosquitto and if everything works as expected the subscriber should receive from Mosquitto what the publisher sends to Mosquitto. An example of sending a test message as a publisher on the topic test/mqtt with the payload “test123”

[root@localhost ~]# mosquitto_pub -d -t test/mqtt -m "test123"
Client mosqpub/2411-localhost. sending CONNECT
Client mosqpub/2411-localhost. received CONNACK
Client mosqpub/2411-localhost. sending PUBLISH (d0, q0, r0, m1, 'test/mqtt', ... (7 bytes))
Client mosqpub/2411-localhost. sending DISCONNECT
[root@localhost ~]#
As can be seen from the subscriber side we now receive the message:
[root@localhost ~]# mosquitto_sub -d -t test/mqtt
Client mosqsub/2384-localhost. sending CONNECT
Client mosqsub/2384-localhost. received CONNACK
Client mosqsub/2384-localhost. sending SUBSCRIBE (Mid: 1, Topic: test/mqtt, QoS: 0)
Client mosqsub/2384-localhost. received SUBACK
Subscribed (mid: 1): 0
Client mosqsub/2384-localhost. received PUBLISH (d0, q0, r0, m0, 'test/mqtt', ... (7 bytes))
test123

The above examples are all working on localhost by default, if you want to publish (or subscribe) to a remote machine you can use the –h option to specify the host. Make sure you have port 1883 (the default port of mqtt) is open and not blocked. As an example of a remote subscription:

mosquitto_sub -h 192.168.1.101 -d -t test/mqtt