If you manage, secure, or plan for IT environments or DevOps, we’d love for you to take our System Management survey. Right now, we’re busy planning on how to make the Assimilation Suite better in 2016. Your responses will be a huge help in giving us a sharp focus on how best to improve IT management for you and others in the IT community. If you can help us out, we’ll send you a small token of our appreciation
On January 2nd we put out version 1.1.2 of the Assimilation System Management Suite – the Happy 2016 release. This release adds enhancements related to best practice analyses and adds support for openSUSE, Scientific, and ScientificFermi Linux – along with a few bug fixes. We also have some surveys that we’d love for people to take – to help direct us in our future work.
As we have in the past, we offer supported free trials of the Linux version of our system management suite – just follow the download link and the instructions you’ll find there.
The Assimilation System Management Suite monitors servers and services automatically – which is way cool! This article explains how to create Assimilation monitoring rules which teach the Assimilation software when and how to use monitoring agents. These rules are the keys to fully automated monitoring. When your monitoring is fully automated, complexity goes down, and availability goes up.
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.
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.
Today’s blog post is about the imperative, absolute necessity for automation in cybersecurity. Those of you who read this blog regularly will note that this has been the theme for a while – with three recent articles about automation and one on the IT best practices project (which is all about automation). In this article we talk about why to automate cybersecurity, what to automate and how to automate cybersecurity.
Getting into security compliance is a big effort. Worse yet, Verizon says 80% of those who get in compliance have trouble staying there. When you discover you’re out of security compliance, there’s typically high drama if an auditor notices, or even higher drama if your security team discovers you’ve let an intruder in. Too much drama and too much elapsed time reduces security and impairs organizational learning.
What’s needed is a way to find these problems right after they’re created – while the people involved still remember what they did and why they did it. This changes the whole dynamic and creates teachable moments instead of high stress drama – before an intruder or auditor finds the weakness.
One of the key things that make DevOps deployments possible is more automation to make things more reliable. These tools include things like Jenkins, Ansible, Chef, Puppet, SaltStack, and even tools like Hubot, and concepts like Infrastructure as Code, Test Automation, and Test Driven Development, Continuous Integration, Continuous Delivery, and ChatOps. These tools have changed the face of system administration in the last decade. Unfortunately, security automation has lagged significantly behind the DevOps movement.