Microsoft has announced a vulnerability in Samba, the widely used SMB/CIFS protocol for Windows/*nix interoperability. The vulnerability exists in versions 3.5.0 to 4.2.0rc4 and allows malicious clients to manipulate the host such that clients can execute code via a netlogon packet.
We know you're sick of updating OpenSSL so we'll keep this short. There is a new SSL vulnerability named FREAK with a published proof of concept. FREAK affects a significant portion of websites, including big names like American Express and the NSA. Like POODLE, FREAK takes advantage of support for legacy cryptographic protocols.
To determine the scope of your exposure to the FREAK attack you need to know what version of OpenSSL is installed on every server. If you've updated since January, you're likely safe. If not, you are likely vulnerable and need to assess the work to be done. With GuardRail's enterprise search that information is trivial to retrieve. Just type in any search term like you would if you were using Google to find a place with good tacos.
Puppet Enterprise is a great platform for automating the configuration and deployment of applications to servers, but as a sophisticated infrastructure management tool with numerous interconnected moving parts-- can be a challenge to troubleshoot when things go awry. This is especially true when dealing with cascading errors that are hard to isolate for resolution. What follows is a short list of some of the more common issues one may encounter, and a few tips on how to troubleshoot and resolve them.
Build once, configure once and run anywhere. Sound familiar? Numerous companies have had a crack at this over the years. Sun was the first with Java and JVM: a platform-independent language and runtime environment that enables developers to build programs that are at once compiled and interpreted, allowing them to be run from anywhere a version of the JVM exists. Docker, the latest company to adopt the mantra, has a similar value proposition--except in this case we’re dealing with servers, not code.
In Part 1 of this article, we presented an overview of Amazon AWS and GuardRail, and discussed how the two marry the best in cloud computing and DevOps. We also learned how GuardRail is not just the premier solution for configuration monitoring, control and automation of AWS offerings like EC2 and S3, but can also work with any number of RESTful services. But enough waxing philosophical—time to put theory into action. And what better way than to follow a fictional organization as it sets up GuardRail monitoring for its AWS cloud infrastructure?
It's not pleasant to think about, but the fact is that when we go to work we are expected to do things. But what are the things that need doing? If we can answer that question without hours of meetings or dozens of emails we can finish our work and do...other things. GuardRail's new Tasks feature provides a lightweight project management system designed especially to maintain quality in a rapidly changing environment.
In July of 2014 Jon Hendren, also known as @fart, began a journey to become a DevOps thought leader. Using his audience of 70k+ followers on Twitter, he spread a simple message: Jon Hendren is a DevOps thought leader.
Over the years, Amazon has become the poster child for all things cloud-related, and for good reason: as one of the initial vendors to embrace the cloud computing paradigm, they were the first to offer widely accessible commercial cloud infrastructure services when it launched EC2 and S3 as part of AWS back in 2006. And now, almost a decade later, the tech giant continues to dominate with a 27% market share of the cloud services market. It's therefore not surprising that for many, Amazon comes to mind first when thinking of cloud computing.
When we set out to create a cloud-based tool for configuration monitoring, we used the tools we knew and wrote GuardRail using JRuby. For our application, JRuby had many good qualities: getting started only required a one line install, the agent only needed to talk out on port 443, and it was platform agnostic. Using JRuby we demonstrated the value of system visibility, attracted our first cohort of customers, and raised the funds to expand ScriptRock. Now we're not only scrapping that agent, we're moving away from agent-based architecture altogether. Here's why.
In a recent episode of the Enterprise Initiatives podcast, our own debonair cofounder Alan Sharp-Paul sat down with host Mike Kavis to talk DevOps, and especially one particularly memorable blog post in which Alan advised that's not wise to look before you leap and "don't automate what you don't understand." That point has been known to cause some contention among certain DevOpserati who often maintain the movement is primarly based on a cultural shift coupled with automation.