Tag: Linux

Categories
Linux Monitoring openSUSE

Installing New Relic Servers on openSUSE

New Relic Servers is an excellent cloud-based server monitoring platform. I maintain a set of servers, both physical and virtual, running a range of operating systems, namely: Debian 7/8, Ubuntu 14.04, CentOS 6/7 and openSUSE 13.2. I work with configuration management (particularly Salt), so maintaining multiple configurations is important in understanding complex environments.

New Relic already provides packages for Debian/Ubuntu, Red Hat, Joyent SmartOS and Windows. For some reason, openSUSE doesn’t get the royal treatment, but they do provide the requisite package files in a tar.gz archive for “Other Linux” systems, so let’s work with that.

Installation

  • Grab the latest release version of New Relic Servers, available from the page below:
    https://rpm.newrelic.com/accounts/<YOUR-NEWRELIC-ACCOUNT-ID>/servers/get_started

server#> wget https://download.newrelic.com/server_monitor/release/newrelic-sysmond-<VERSION>-linux.tar.gz

  • Decompress the downloaded archive.
server#> tar -zxf newrelic-sysmond-<VERSION>-linux.tar.gz
  • cd into the resulting directory.
server#> cd newrelic-sysmond-<VERSION>-linux
  • Important: Create the configuration and log directories.
server#> mkdir /etc/newrelic

server#> mkdir -m 750 /var/log/newrelic

  • Copy the example nrsysmond.cfg file to /etc/newrelic.
server#> cp nrsysmond.cfg /etc/newrelic
  • Edit the config file and enter your New Relic license key in the appropriate place, as below. No other changes should be necessary.
server#> vim /etc/newrelic/nrsysmond.cfg
[...]

license_key=<NEWRELIC-LICENSE-KEY>

[...]
  • Copy the daemon binary into somewhere that’s readily available on your path. /usr/local/sbin is a reliable choice.
server#> cp daemon/nrsysmond.x64 /usr/local/sbin/nrsysmond

 

Testing

Let’s go ahead and run nrsysmond. Remember to pass it the config file with the -c option.

server#> nrsysmond -c /etc/newrelic/nrsysmond.cfg

All going well, your openSUSE server will now be reporting to New Relic and you will be able to monitor it on your dashboard.

 

systemd service

No daemon is of any use without a decent init script or, in this case, a systemd service.

Disclaimer: I’ve only written a handful of systemd services, and they’ve all been pretty simple in nature. This is by no means a “good” service, but it seems to work fine as a means to manage New Relic Servers in a reliable fashion.

  • Create the systemd service file.
server#> vim /usr/lib/systemd/system/newrelic-sysmond.service
[Unit]
Description=Starts and stops the New Relic Server Monitor Daemon.
After=syslog.target network.target
[Service]
Type=forking
User=root
WorkingDirectory=/tmp
ExecStart=/usr/local/sbin/nrsysmond -c /etc/newrelic/nrsysmond.cfg
ExecStop=/usr/bin/pkill nrsysmond
Restart=on-failure
PIDFile=/var/run/nrsysmond.pid
[Install]
WantedBy=multi-user.target
  • Reload the systemd manager configuration.
server#> systemctl daemon-reload
  • Start the new systemd service.
server#> systemctl start newrelic-sysmond.service
  • If you want New Relic to start on system boot, you can enable the service.
server#> systemctl enable newrelic-sysmond.service

 

And that should be it! All going well, you now have a functional New Relic install on openSUSE with a working systemd service.

Categories
Development Linux Ubuntu Ubuntu SDK

uLuas – Developing a real-time Luas app for Ubuntu

uLuas logoOver the last few weeks I’ve been working on a project called uLuas. uLuas is an open source smartphone app developed using the Ubuntu SDK. It provides real-time tram stop information for Dublin’s Luas light rail service. In this post I’d like to talk about my reasons for developing this application and why I chose the Ubuntu platform.

First – and most importantly – I live and work in Dublin and commute daily using Luas. I rely on the Luas real-time passenger information (RTPI) system to provide me with information on stop times and, on unfortunate occasions, service stoppages. To consume this information, I use a number of end-user services, including the Luas website, Real Time Ireland Android app and, despite crashing on every second launch, the Luas Android app. While the backend data that these apps play with is impressive, I feel that they are presented pretty poorly, being essentially wrapped web apps with non-native and clunky interfaces.

I’ve been following the development of Ubuntu for Phones/Tablets (“Ubuntu Touch”) since its announcement just over a year ago. What excited me about it wasn’t necessarily the idea of having Ubuntu on my phone, but instead the consolidation (or “convergence”, as Canonical call it) of the code base, meaning a standardised platform to develop for. Up until this point, developing an app for Ubuntu meant relying on numerous external tools using Gtk+ bindings for drawing GUIs. The Ubuntu SDK, which was announced around the same time as Ubuntu Touch, is based around Qt Quick, which uses QML for GUI markup and JavaScript for programmatic elements. I skimmed through the documentation and followed the Currency Converter tutorial, then never did much more than that until late last year.

After the release of Ubuntu Touch 1.0, which was a release aimed at developers, I decided to flash it to my Nexus 7 and Samsung Galaxy S2. While I could see the potential in the OS, there were still some apps missing that I would require for a device to be my daily driver. One of the missing elements was an app to track the real-time information for the Luas. A quick web search for “Luas API” later and I stumbled upon Neil Cremins’ Luas PHP endpoint. The endpoint consists of a simple PHP script which, when called, returns inbound and outbound tram times for a specific stop in a meaningful JSON format:

aaron@zefram:~$ curl 'http://localhost/luas-api.php?action=times&station=BLA'

{"message":"All services operating normally",
"trams":[{"direction":"Inbound","dueMinutes":"2","destination":"Connolly"},{"direction":"Inbound","dueMinutes":"7","destination":"The Point"},{"direction":"Inbound","dueMinutes":"14","destination":"Connolly"},{"direction":"Inbound","dueMinutes":"18","destination":"The Point"},{"direction":"Outbound","dueMinutes":"1","destination":"Tallaght"},{"direction":"Outbound","dueMinutes":"5","destination":"Saggart"},{"direction":"Outbound","dueMinutes":"9","destination":"Tallaght"},{"direction":"Outbound","dueMinutes":"18","destination":"Saggart"}]}

Armed with my data source and a server to host the PHP script on, I went to work on the actual application. I opted for an interface utilising Ubuntu’s Tabs class, with one tab each for the Luas Red and Green Lines. Choosing a stop is done with an unexpanded OptionSelector which, when tapped, expands to reveal a scrollable list of stops. I have a dedicated Message box which receives updates straight from the Luas API during a service disruption. I even made the box change colour from green to red when such an event occurs – I’m overly proud of that achievement. Finally a list of inbound and outbound trams for the selected stop is presented to the user, with expected times in minutes.

Red Line and Green Line tabs with typical displays:

  red_line_0.17green_line_0.17

Example of an RTPI outage, gracefully handled by uLuas. The Message comes straight from the Luas API:

rtpi_error

Expanded OptionSelector:

OptionSelector

The dedicated site for uLuas can be found at my development website:
http://uluas.thecosmicfrog.org

The source code for uLuas is released under the GNU General Public License and is available on my GitHub profile at the link below:
https://github.com/thecosmicfrog/uluas

uLuas icon kindly created and donated by Sam Hewitt.

Categories
Linux Ubuntu

Getting Ubuntu notifications to appear on the correct monitor

Like many of you, I use Ubuntu at work with a dual-monitor setup. One of the most frustrating things I’ve always found is its behavior regarding pop-up notifications. I regularly miss new emails or chat messages due to the notification popping up on my secondary monitor, right on my eye’s blind spot.

I’ve been putting up with this up until now, deeming it to be a bug in either Unity or notify-osd itself. I had always intended on filing a bug report, but I’m glad I never did; it turns out this is desired behavior. Fair enough, I suppose, but the fix I have found is far more correct behavior in my eyes (literally – heh…).

Rather than only displaying notifications on the connected monitor, entering the below command at the terminal will make it so that notifications appear on the active monitor, i.e. the monitor currently in use. Far more sensible, no?

gsettings set com.canonical.notify-osd multihead-mode focus-follow

If you’re new to Linux, or if entering odd-looking commands into text-based interfaces makes you uncomfortable, you can also apply the above fix graphically using the following steps:

  1. Open the Unity Dash (Windows/Super key).
  2. Search for and launch dconf Editor.
  3. On the left-hand menu, expand apps and click notify-osd.
  4. Next to the multihead-mode entry, double-click dont-focus-follow and change it to focus-follow.

And that’s it. Your Ubuntu notifications should now appear on the screen you are actually working on. Resetting it to the default behavior is as simple as adding back in the dont- before focus-follow.

Categories
Final Year Project

Final Year Project: Introduction

I have to admit that I wrote the Raspberry Pi off at first. I mean, my initial description of it as a “slow Linux computer” are technically correct, but I never really thought of looking at it for what it really is – a cheap, small and, least importantly, slow Linux computer.

Top-down view of Raspberry Pi
Top-down view of Raspberry Pi

I’ve been actively using Linux since 2009, with Ubuntu eventually becoming my primary OS in early 2010.  I think it was the early descriptions of the Pi as a teaching tool for programming that put me off. I couldn’t comprehend why a low-spec, awkwardly-shaped computer would be desirable as a platform to teach the art of coding, particularly when most schools have perfectly capable machines already in their possession.

But then I got my hands on one. And, almost immediately, I realized that the Pi really is something special.

My Final Year Project is entitled Smartphone-controlled media streaming application for Raspberry Pi. The idea behind this project is to create an open source web-based software stack for the Pi which allows it to be used as both a media streaming server (to be accessed remotely via a browser) and as a TV-connected home media center, utilizing the Pi’s HDMI output capabilities. I aim to achieve this using web applications instead of native GTK+ or Qt interfaces. The benefit of this, besides portability, is a unified interface for both the remote streaming feature and the intention for the device to be used as a HTPC (Home Theater PC).

The niche of this project, and arguably the most challenging aspect of it, is the requirement for the application to be controlled by a smartphone. This can’t just involve writing an app that can access the same data store as the web application, but must be able to control the web interface as if it were a standard remote control for a set-top box or smart TV interface.

High-level architecture of project
High-level architecture of project

I like Python. But, due to a combination of time constraints and how easily I’m distracted by shiny objects, I’ve written very little of it. Coupled with this, I’ve been intrigued by the Django framework for a while now. Partly due to its maturity and its wide community of developers, I’ve decided that it would be a good fit for the user-facing requirements of this project. The other part of my reasoning isn’t so much reasoning as it is curiosity. Other technologies I intend on using are: Nginx for the web server, PostgreSQL for the back-end data store, HTML, CSS and JavaScript for the web design and Java/SL4A for the mobile application, many of which I also have little experience with.

The way I figure it, what’s the point of engaging in a project if you’re not going to step outside your comfort zone so many times that the end goal appears to be a blurry vision of accomplishment, led to by a path made mostly of fire? And stack traces. Millions of them. And they’re also on fire.