Last weekend, I had the honor of giving the opening keynote on Friday at the 2015 Ohio LinuxFest and a session presentation on the Assimilation project the next day. Both talks were very well-received, but the reception the Assimilation project talk received from the standing-room audience was extraordinary. So it seems good to give a summary of the talk and why I think they resonated so strongly to it.
In a previous blog post, I outlined the characteristics of a CMDB for the DevOps era. In this post I give my somewhat-biased view of how well the Assimilation System Management Suite CMDB meets those needs.
CMDBs have a bad reputation in many circles. They are seen as expensive, have been associated with costly IT failures, high overhead clumsy processes, are reviled by some, and are thought to be incompatible with DevOps. In my opinion, they don’t have to be that way. The idea of a database that knows everything about your IT environment, replaces manual documentation and springboards automation is incredibly attractive. What would a CMDB look like that is easy to install, and easier to maintain – one that followed the DevOps mantra of automating everything? This post explores that question.
We fill our lives with things designed to make them easier… In many cases, these things we get to make our lives easier wind up making it more complex. Nowhere is this more apparent than in IT. We have so many choices of ways to create services, to deploy them, and to manage them. I’ve been extensively involved with high-availability work since 1998. One of my mantras in high-availability is “Complexity is the Enemy of Reliability” – and so it is. If you add parts to a thing, more things will fail – period. In high-availability, we add high-availability software – which makes it more complex, and hence less reliable. But we get something back instead – improved availability.
After a few mental missteps documented by previous blog posts (here and there), this is what I think of as a pretty reasonable approach to packet encryption in the Assimilation Project. Although those two posts are now obsolete, the background post I wrote is still relevant. I’ve learned a lot about crypto in the process […]
I’ve been asked to give the keynote address at the 2015 Cascadia IT conference. For my keynote, I’d like to tell stories of their contributions – large and small – and how they helped and how they were uniquely valuable. Although I have a number of stories of how various IT admins (system, network, security, etc.) have contributed to my projects (Linux-HA/Pacemaker and the Assimilation Project), I’m looking for more. This post is a request to send me your stories of how IT admins have contributed to open source projects in large or small ways.
Share a link to this post to your friends and your favorite social media sites!!
In this article, we talk in more detail about the Assimilation Project’s reliable UDP protocol, our decision to avoid session keys, factors influencing our initial choice of crypto libraries, and touch on key revocation. So, like before we’re looking forward to your comments on our design choices. Like before, grab your thinking cap, sit down with your crypto buddies and think hard about what we’ve done.
This article outlines our approach to keys and key management given our unique problems in a pragmatic and effective way. Although we will use crypto libraries with well-proven algorithms, we will use them in slightly unconventional ways. So, get your crypto buddies, grab a beverage (adult or otherwise), put on your thinking cap, and think hard about how we’re planning on approaching these challenges. Although I’ve tried to think all this through, I’m not a crypto expert – which is why I’m asking for your help.
Since its inception, the open source Assimilation project has been concerned with security, and paranoid at every opportunity. Like a lot of software, it has serious security concerns. On the one hand, our nanoprobes run on every server in the enterprise and exercise root privileges – creating a potentially dangerous attack surface. On the other hand, we incrementally create a high-value database which has fine-grained and up-to-date information about everything in the environment – software versions, ports, services, IP addresses and MAC addresses, known security vulnerabilities – a veritable treasure map for an attacker. This article details why cryptography is essential for communication in this environment, and some unique aspects of the problem we’re solving that affect how we use it. It is our hope our readers (this means you!) will give us a thorough flogging^H^H^H^H^H^H^H review of how we use cryptography in our software in this article and the next.
