OUCE 2015: Bad Voltage Live

Every year at the OpenNMS Users Conference (OUCE) we have a good time. In fact, learning a lot about OpenNMS goes hand in hand with having fun.

At this year’s SCaLE conference, the team behind the Bad Voltage podcast was there to do a live version of the show. You can watch it on-line and see it went pretty well, and this gave me the idea to invite the gang over to Germany to do it again at the OUCE.

Since there may be one or two of my three readers who are unaware of Bad Voltage, I thought I’d post this little primer to bring you up to speed.

Bad Voltage is a biweekly podcast focused on open source software, technology in general and pretty much anything else that comes across the sometimes twisted minds of the hosts. They deliver it in a funny manner, sometimes NSFW, and for four guys with big personalities they do a good job of sharing the stage with each other. As I write this they have done 47 episodes, which is actually quite a nice run. For anyone who has done one or thought about doing a periodic podcast or column, know that after the first few it can be hard to keep going. It is a testament to how well these guys work together that the show has endured. Believe it or not, I actually put time into these posts and even I find it hard to produce a steady amount of content. I can’t imagine the work needed to coordinate four busy guys to create what is usually a good hour or three of podcast. (grin)

Bad Voltage as The Beatles

Anyway, I want to introduce you to the four Bad Voltage team members, and I thought it would be a useful analogy to compare them to the Beatles. As I doubt anyone who finds this blog is too young to not know of the Beatles, it should aid in getting to understand the players.

Bad Voltage - Jono Bacon Jono Bacon is Paul. If you have heard of anyone from Bad Voltage, chances are it is Jono. He’s kind of like the Elvis of open source. He was a presenter for LugRadio but is probably best known for his time at Canonical where he served as the community manager for Ubuntu. He literally wrote the book on open source communities. He is now building communities for the XPRIZE foundation as well as writing articles for opensource.com and Forbes and occasionally making loud music. He’s Paul because is he one of the most recognizable people on the team, and he secretly wishes I had compared him to John.

Bad Voltage - Bryan Lunduke Bryan Lunduke is John. He gets to be John because he has heartfelt opinions about everything, and usually good arguments (well, arguments at least) to back them up. He has passion, much of which he puts into promoting OpenSUSE. I’ve never met Bryan in person, but we’ve missed each other on numerous occasions. I missed him at SCaLE, he missed the Bad Voltage show I was on, and I missed him again at OSCON. And I’ll miss him in Fulda, as his wife is due to deliver their second child about that time, but he will be there virtually. He adds depth the the team.

Bad Voltage - Jeremy Garcia Jeremy Garcia is George. Although none of these guys could be described as “quiet”, he is the most reserved of the bunch, but when he opens his mouth he always has something interesting to say. You can’t be part of this group and be a wallflower. I’m not sure if he has a day job, but fifteen (!) years ago he founded Linuxquestions.org and has been a supporter of open source software even longer. He adds a nice, rational balance to the group.

 

Bad Voltage - Stuart Langridge Stuart is Ringo, known to his friends as “Aq” (short for “Aquarius” – long story). He is pretty unfiltered and will hold forth on topics as wide ranging as works of science fiction or why there should be no fruit in beer. He was also a member of LugRadio as well as an employee of Canonical, and now codes and runs his own consulting firm (when he is not selling his body on the streets of Birmingham). If there was a Bad Voltage buzzword bingo, you could count on him to be the first to say “bollocks”. He adds a random element to the group that can often take the discussion in interesting directions.

They have been working hard behind the scenes to plan out a great show for the OUCE. Since many of the attendees tend not to be from the US or the UK, it is hoped that the show will translate well for the whole audience, and to make sure that happens we will be serving beer (if you are into that sort of thing). If you were thinking about coming to the conference, perhaps this will push you over the top and make you register.

But remember, you don’t have to attend the OUCE to see the show. We do ask that you register and pony up 5€. Why? Because we know you slackers all too well and you might sign up and then decide to blow it off to binge on Regular Ordinary Swedish Meal Time. Space is limited, and we don’t want to turn people away and then have space left open. Plus, you’ll be able to get that back in beer, and the show itself promises to be priceless and something you don’t want to miss.

If that isn’t enough, there is a non-zero chance that at least one of the performers will do something obscenely biological (and perhaps even illegal in Germany), and you could say “I was there”.

Convince Your Boss to Send You to the OUCE

With this year’s OpenNMS Users Conference a little over a month away, I plan to be writing about it more in the run up to the event. I figured I should probably start on why you should go and, better yet, how to convince your boss to pay for the trip.

First off, if you aren’t using OpenNMS, why not? (grin)

In all seriousness, if you are happy with your network management solution you can stop reading now. But if you aren’t happy, are in the process of considering alternatives, or if you have a serious interest in discovering the benefits of an open source network management platform, the money you will spend to investigate OpenNMS through the Users Conference is a rounding error compared to the price of similar commercial solutions.

Second, OpenNMS is more of a platform than an application. I know of a number of organizations who manage billion dollar budgets using Microsoft Excel, but it didn’t work for them out of the box. They had to build the spreadsheets, integrate it with databases and other applications, but now they have a custom system that fits their needs. Most network management applications require the user to adapt their processes to fit the application. For most IT organizations those processes are what differentiate them from their competitors, so it makes more sense to use a platform like OpenNMS which can be customized to better complement them instead of the other way around.

Third, OpenNMS does have a steep learning curve. It is a broad and powerful tool but it does require an investment in time in order to realize its full potential. One way to get such knowledge would be to attend a week-long training class at the OpenNMS HQ. The cost would be US$2500 plus travel.

Contrast this with the OUCE. The full four day package runs 1000€, currently about US$1100, or less than half the price of the standard training course. Even with travel expenses (assuming you aren’t in Germany in particular or Europe in general) it should make more sense to go to the OUCE than to the usual training course (plus, the next one isn’t until January of next year). If you don’t have the need to go to the one day OpenNMS Bootcamp, it is even less expensive. It makes good financial sense.

Fourth, this is a *users* conference. If you come to training you will most likely get to listen to me for five days. At the OUCE you get to meet and talk with the people who *use* OpenNMS. Got a common problem? Find out how others solved it using OpenNMS. Got a weird problem? I can guarantee that someone at the conference will have a weirder one that they used OpenNMS to fix. The initial list of accepted talks is awesome and will only get better.

Fifth, a lot of the key people behind OpenNMS will be there as well (including yours truly) and so you can experience first hand what makes the OpenNMS community so special. Plus, since we don’t “unveil” new features, you can see first hand what is currently available in the development version of OpenNMS, including “big data” storage, new and improved graphing, elasticsearch integration and distributed polling via “minions”.

Finally, it’s a lot of fun. I can remember meeting Ian Norton during an OUCE several years ago. He had been forced to attend the conference by his (now previous) employer and was very unhappy about it. Not knowing who I was, he candidly ranted about issues he saw with the product. I assured him that we would work hard over the next two days to address them. Now he is one of our biggest supporters, and all it took was two days to “get it” and understand what makes OpenNMS so magical (in the interest of full disclosure, schnapps was involved).

In conclusion, if you are not using OpenNMS you are probably paying too much for a lesser solution. This may not be true in your particular case, but you should at least seriously investigate the possibility. It makes financial sense to do this at the Users Conference, even with travel expenses, plus you can see how real users, just like you, are getting the most value out of the tool. And even if you decide OpenNMS is not for you, you’ll have had some fun and can rest assured you did your due diligence when examining management options for your employer.

Hope to see you there.

Case Study: Why You Want OpenNMS Support

I wanted to share a story about a support case I worked on recently that might serve to justify the usefulness of commercial OpenNMS Support to folks thinking about it. As always, OpenNMS is published under an open source license and so commercial support is never a requirement, but as this story involves commercial software I thought it might be useful to share it.

We have a client that handles a lot of sensitive information, to the point that they have an extremely hardened network environment that makes it difficult to manage. They place a separate copy of OpenNMS into this “sphere” just to manage the machines inside it, and they have configured the webUI to be accessed over HTTPS as the only access from the outside.

Recently, a security audit turned up this message:


Red Hat Linux 6.6 weak-crypto-key
3 Weak Cryptographic Key Fail "The following TLS cipher suites use
Diffie-Hellman keys smaller than 1024 bits: *
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (768-bit DH key) *
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (768-bit DH key)" "Use a Stronger Key If
the weak key is used in an X.509 certificate (for example for an HTTPS
server), generate a longer key and recreate the certificate. Please also
refer to NIST's recommendations on cryptographic algorithms and key
lengths (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
) ." Vulnerable

and they opened a support ticket asking for advice on how to fix it.

I had some issues with the error message right off the bat. The key used was 2048 bits, so my guess is that the algorithm is weak and not the key. The error message seems to suggest, however, that a longer key would fix the problem.

Anyway, this should be simple to fix. The jetty.xml file in the OpenNMS configuration directory lets you exclude certain ciphers, so I just had the customer add these two to the list and restart OpenNMS.

And then we waited for the nightly scan to run.

This fixed the issue with the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher but not the first one. Nothing we did seemed to help, so I installed sslscan on my test machine to try and duplicate the issue. I got a different list of ciphers, and since openssl uses different name for the ciphers than Java, and it was a bit of a pain to try and map them. I couldn’t get sslscan to show the same vulnerabilities as the tool they were using.

We finally found out that the tool was Nexpose by Rapid 7. I wasn’t familiar with the tool, but I found that I could download a trial version. So I set up a VM and installed the “Community Edition”.

Note: this has nothing to do with open core, which often refers to their “free” version as the “community” version. Nexpose is 100% commercial. They use “community” to mean “community supported”, but it is kind of confusing, like when Bertolli’s markets “light” olive oil which means “light tasting” and not low in calories.

I had to fill out a web form and wait about a day for the key to show up. I had installed the exact version of OpenNMS that the client was using on my VM, so my hope was that I could recreate the errors.

First, I had to increase the memory to the VM. Nexpose is written in Java and is a memory hog, but so is OpenNMS, and it was some work to get them to play nice together on the same machine. But once I got it running, it wasn’t too hard to recreate the problem.

The Nexpose user interface isn’t totally intuitive, but I was able to add the IP address of the local machine and get a scan to kick off without having to read any documentation. The output came as a CVS file, but you could also examine the output from within the UI.

The scan reported the same two errors, and just like before I was able to remove the “TLS_DHE_RSA_WITH_AES_128_CBC_SHA” one just by excluding it in jetty.xml, but the second one would not go away. I found a list of ciphers supported by Java, but nothing exactly matched “TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and I tried almost all of the combinations for similar TLS ciphers.

Then it dawned on me to try “SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and the error went away. I guess in retrospect it was obvious but I was pretty much focused on TLS based ciphers and it didn’t dawn on me that this would be the error with Nexpose.

It was extremely frustrating, but as my customer was being beat up about it I was glad that we could get the system to pass the audit. While this was totally an issue with the scanning software and not OpenNMS, it would have been hard to figure out without the help we were happy to give.

It may not surprise anyone that a large number of OpenNMS support issues tend to be related to products from other vendors. Usually most of them can be classified as a poor implementation of the SNMP standard, but occasionally we get something like this.

Our clients tend to be incredibly smart and good at their jobs, but having access to the folks that actually make OpenNMS can sometimes save enough time and headache to more than offset the cost of support.

Welcome Costa Rica! (Country 28)

While I have never been able to personally visit Costa Rica (it is on my list) I am happy to announce that we now have a commercial customer from their, making it the 28th unique country for OpenNMS.

They join the following countries:

Australia, Canada, Chile, China, Denmark, Egypt, Finland, France, Germany, Honduras, India, Ireland, Israel, Italy, Japan, Malta, Mexico, The Netherlands, Portugal, Singapore, Spain, Sweden, Switzerland, Trinidad, the UAE, the UK and the US.