I will be participating in an expert panel to discuss how to effectively bridge the infosec/DevOps divide. Learn how you can too, 2pm ET, June 20, 2018.
Tenable Webinar Landing Page
After my session “Setting Up Your Own Private, Secured Package Repository” at the PowerShell DevOps Summit, there has been more interest in the PluralSight course I built to help automation developers get started with Chocolately.
Chocolatey NuGet Essentials for Automation Pros unpacks the Chocolatey technology set and helps you understand what role it plays in deployment automation, and how it can deliver critical value to your software deployment automation tool chain whether you live in a DevOps world or a Traditional Ops world.
I really enjoyed speaking at the PowerShell Summit and meeting so many Windows DevOps enthusiasts!
As promised here are links to the video, the slides and the code.
Slides and Code
My PluralSight Course Chocolatey NuGet Essentials Automation Pros goes into much more detail on using Chocolatey packaging technology to accelerate your software deployment automation.
Session Abstract: Security and availability are good defensive reasons to curate public packages into a private repository, but there are many positive reasons as well!
I lead a team that builds highly shared, deep-in-the-stack automation at a large SaaS company that has many software stacks in AWS. This automation includes things like installing security scanners, log collection agents and monitoring agents - all for both Windows and Linux.
I inherited a lot of this code and was working together with a team member and a technician from the software company for one of these agents that was giving us trouble, when I realized we could improve the ruggedness of our code significantly!
In one of the DevOps automation testing environments I work with I recently came across an AD OU that had over 75,000 unused computer records. This environment is used for repeated testing of entire automation stacks with unique computer names, so it is normal that these records would pile up. While this particular OU was for Linux machines - the problem obviously affected both Windows and Linux across all OUs.
Being that it is the year 2018 I thought finding a ready-made solution on the web would be child’s play (oh Murphy - why do you plant those thoughts in my head!).
As it is with the Toolsmithing nature, when I could not find a simple solution, I had a strong desire to conjure a tool for everyone.
There has been a nasty rumor going around that EBS volumes no longer need initialization (formerly pre-warming). The Amazon page that talks about this mentions that it is no longer needed, but that it IS needed for EBS volumes created from snapshots.
Although custom and Amazon AMIs are stored as snapshots, many people I talk to have come to believe that EBS volumes simply don’t need initialization, no matter what. I sought clarification from AWS support and learned that the boot volumes of our custom AMIs definitely need initialization as do AWS AMIs. Basically initialization is not needed if you just created a fresh EBS volume (console or Cloud Formation) that has never been snapshotted as part of an AMI.
The newest utility advised by Amazon is the File IO testing utility known as FIO. I decided to write a provisioning automation utility script that would automatically download this and run it or schedule it. Since I have been looking for excuses to improve my Bash coding skills - I decided to write the provisioning automation in both Bash and PowerShell.
I will be speaking at the PowerShell and DevOps Summit 2018 on the topic of Setting Up Your Own Private, Secured Package Repository
Abstract: Security and availability are good defensive reasons to curate public packages into a private repository, but there are many positive reasons as well! We will cover the benefits of a dedicated, private repository, as well as enabling secure, global reach and an analysis of repository options.
Over time I’ve found there are many reasons why I may be asked to debug systems I do not have convenient access to.
It is painstaking to get lists of diagnostic information in circumstances such as these because it requires a lot of information relaying and lag times.
In the past, I have done a survey of the available options for systems information utilities to help get a dump of a system’s configuration information.
This post discusses the key selection criteria for such a utility and provides automation code (including oneliners) for collecting the diagnostics information with minimal relaying of instructions.
Automation of Windows Updates is generally done by calling wusa.exe against a .MSU file. When wusa.exe experiences a failure the messages are typically obscure and hard to diagnose. The underlying error messages, however, are frequently easy to understand and resolve.
The secret is to have wusa.exe do verbose logging in it’s standard exported windows event format and then use the PowerShell event message CMDLets to query that log - automatically, everytime you have an error.
Although focused on applying updates with wusa.exe, this article contains most of my logging best practices for automation coding when calling automated sub-processes.