There, I said it! Containers won’t fix every application, they won’t replace your server farm, and sadly they won’t do your laundry.

Someone needed to say something in this world of marketing buzzwords and hype machines. “I volunteer as tribute.”

I work with a lot of container tools and platforms, and I have to say the technologies are fantastic! However, I was a SysAdmin for about a decade and worked in the MidWest to boot. (I say that because technology in the United States seems to start on the coasts and works its way to the middle of the country.)

Containers DO serve a great purpose: they isolate a running application into isolation and only give access to host resources that are absolutely necessary.

Containers DO make it easy to try out new technologies and applications. My home lab runs several web hosting tools (like WordPress and Hugo), gaming platforms, and home automation tools. To figure out which ones I liked best, I could spin up a basic image with a couple of commands.

Containers DO allow you to create applications that are self-healing, that can be deployed through automated pipelines, and provide for a dense application population.

However…

Containers DON’T replace the operating system. Guess what? The code running in containers is still Linux (and some are a few Windows images too). The orchestrator or operating system running underneath your container… an OS! The only question is how deeply that OS is obfuscated away.

Containers DON’T have a migration path like P2V (physical-to-virtual) did in the dawn of virtualization.

Containers AREN’T designed to absorb your 100GB legacy application that runs on an antiquated code base.

However…again…

I will say container technologies have come a long way in the last few years. The routes to production have become much more straightforward and more opinionated.

Container technologies are no longer the Wild West. So, while containers may not be a one-size-fits-all solution like the hype machine would have you believe, I do think there are a growing number of use cases.

I picture a long highway that stretches past the horizon. Each exit is a different stopping-off point for an individual workload. For instance:

Exit 1) Maybe you are a small business with a web server, a sales portal, and a backend database. Do you really need a 6-node Kubernetes cluster hosted on a cloud provider? I’d say not.

In this scenario, running a single server (with automated backups, of course) and running your workloads in a series of Podman pods would make sense.

Exit 2) At some point, you decide you want to start adding features to your sales application. Now, you may add 2 or 3 more servers to serve as Dev and QA environments. 

This exit is a little more crowded, but you can still get by with managing your container infrastructure by hand. 

Exit 8A) Let’s say your small sales company expands at a rapid and unanticipated rate. Your 3-4 pods with a couple of containers each are now at over a hundred pods with multiple containers each. You have measurable ebbs and flows of traffic throughout the day.

Do you really want to run each pod by hand? Do you really want your applications to run at peak capacity at 3 AM when you get no traffic to your web properties?

Now we start talking about container orchestration. Now we start discussing bringing in Kubernetes. Now you can build each of dozens of components by yourself, or you can look at the next exit:

Exit 8B) Each cloud provider has their own managed (read opinionated) implementation of Kubernetes, where all the hard decisions are made for you. 

All your operations teams have to do is spin them up, instantiate some users, and start deploying (grossly over-simplified, but you get the idea).

In fact, my company, Red Hat, has one of the coolest (in this dude’s opinion) container platforms out there: OpenShift! 

While I am just a Linux SysAdmin at heart, I can genuinely appreciate what containers and platforms like Kubernetes and OpenShift are trying to accomplish.

I host a live stream on Twitch and YouTube to talk about Red Hat Enterprise Linux. This next week, January 11th, we’re having some of the OpenShift team on to talk about running virtual machines on their platform! (See the comments for the link.)

I am in love with containers; my home lab lives by them. I believe it is necessary to take a realistic approach to move into the container space. One size does not fit all.

——

Disclaimer: This is an opinion piece of my own making. It is neither sponsored nor commissioned by Red Hat.

I was recently asked, “Why call yourself the IT Guy? Why not just use your name?” Great question! In the professional world, we are encouraged to “build a professional brand,” I just took it to an entirely different level.

There were a few minor reasons. One of which is privacy. I initially didn’t want my full name publicized all over the Internet. However, I eventually realized that anyone that wanted to figure out who I was badly enough could follow the breadcrumbs to LinkedIn. 

Another more humorous reason was that I used to hang out regularly on Linux Unplugged, a live podcast that features a Mumble room for guests to jump on and be a part of the hosts’ discussion. When I first joined, I was “erich1527”. Little did I know that there was an Erich who worked with an open-source project and frequently came to hang out on the show as well. Having two Eric’s made it confusing for the host!

When the IT Guy was born, I worked full-time as a Systems Administrator and part-time trying to start my own IT Consulting company in the Kansas City area. Granted, the consulting business withered away as life changed, kids came into the picture, and priorities shifted. However, it gave me the branding I wanted to create!

I had a client at the time who had me handling an office move. When I walked in the day of the move, the lady behind the front desk leaned into the main conference room and, to her boss, said, “Hey the IT Guy is here.” I was hooked!

I loved how simple the name was: “Eric the IT Guy”. It was generic but appropriate. The IT Guy could be any of us who deal a lot with technology and trying to get it to work. (Obviously, some of you might have to be the IT Gal…but I digress.)

I had colleagues in the technology space who helped me find a voice. I borrowed equipment from them, recorded sample episodes, started appearing on podcasts as The IT Guy. It stuck. It felt right!

When I realized that the brand was working, I was at a DevOps conference here in Kansas City. I introduced myself as Eric, sporting my GitLab work t-shirt at the time. The dude I was chatting with said, “Wait. Eric…Eric…The IT Guy?” My response was a huge smile and “The one and only!”

Some of you may laugh at the name Eric the IT Guy, but hey, it works. As the IT Guy, I try to help educate my fellow technologists. I try to bring exciting technologies to the forefront. I try to teach methodologies and techniques that can save you time and trouble that I dealt with as a Systems Administrator.

Do you need to give yourself some cool nickname or create a personal logo? Probably not. Do you need to network, build connections, and share your knowledge? Most definitely!

If you aren’t sure how to grow your network, you can start by adding me! I am just about everywhere as @itguyeric. Find me, let’s chat; that’s all it takes to get started! One person, one conversation.

We tend to associate free with good. That’s not the case though when what is free is unauthorized root-level access to your Linux systems! On January 26, 2021, a vulnerability, CVE-2021-3156, was disclosed that affects just about every Linux or Unix distribution that utilizes the sudo functionality.

TLDR: You need to update your operating system as soon as possible to ensure you have the patch.

Now that you have scheduled emergency patching windows for all your impacted systems . . . you did right? Let’s get into how this vulnerability works and what the potential impact is.

On a healthy system, you have to run a su command and provide the root password or have your account authorized in the /etc/sudoers file to gain administrative level access to a Linux system. The Baron Samedit bug, however, utilizes a buffer overflow in the Sudo logic to allow a non-privileged account to bypass this security mechanism and run commands with root-level privileges.

While running a sudo command in shell mode (either with the -s or -i argument), special characters must be escaped with a backslash / character. With this vulnerability, however, you can add an extra backslash to any command. This will cause sudo to skip the policy review step where it reads /etc/sudoers to ensure the executing account has sudo privileges. Now with ill-gotten access to root-level privileges, a bad actor could do anything to a compromised system.

You can test this for yourself by logging into a Linux system with a non-privileged account and running:

$ sudoedit -s /

If the prompt returns sudoedit: your system is vulnerable and needs to be patched. However, if your system returns a usage description, your system has been patched and is no longer susceptible to this attack.

This vulnerability was discovered by independent testing by Qualys Inc. an information security and compliance company. Their research found that Baron Samedit was actually introduced in version 1.8.2 released, get this, 10 years ago! This bug has been in the wild for almost a decade! It impacts legacy versions 1.8

Rarely do we see a bug with such a wide pool of targets. Sudo is utilized in Unix and Linux systems everywhere. This impacts popular distributions like Red Hat Enterprise Linux, Ubuntu, Debian, SUSE, Fedora, and so on. Even BSD and other Unix derivatives are not immune to CVE-2021-3145. The risk of any bad actor gaining root-level rights to your systems cannot be overstated. Once running as root, your system can become a slave to botnets, used for crypto-mining, or exploited to retrieve sensitive data.

Distribution	Fixed Version	More Details
Red Hat Enterprise Linux 8	1.8.29-6.el8_3.1	Advisory
Ubuntu 20.04	1.8.31-1ubuntu1.2	Advisory
SUSE Enterprise Linux 15	1.8.22-4.15.1	Advisory
openSUSE Leap 15.2	1.8.22-lp152.8.6.1	Advisory
Fedora 33	1.9.5p2-1.fc33	Advisory
Debian 10	1.8.27-1+deb10u3	Advisory
Arch Linux	1.9.5.p2-1	Advisory
Gentoo	1.9.5.p2	Advisory

If you would like to read more about Baron Samedit and the deeper, technical explanation of how this vulnerability was found and how it works, Qualys published an in-depth blog on their findings: CVE-2021-3156: Heap-Based Buffer Overflow in Sudo

You maybe wondering the same thing I was . . . Where in the world did Qualys get the name Baron Samedit? Turns out, it’s a play on sudoedit and Baron Samedi. According to Voodoo mythology, Baron Samedi is the Loa (god) of the Dead. He is a chaotic spirit who spends his time smoking, drinking, and well possessing others. This ‘spirit’ even attempts to ensnare everyone’s favorite secret agent, James Bond.

Just like 007, we need to overcome this new foe, Baron Samedit. Patch your systems…

—
Additional Reading:
CVE.Mitre.Org: 2021-3156
Sudo.ws: Buffer overflow in command line unescaping
ZDNet: 10-year-old Sudo Bug lets Linux users gain root-level access

This post originally appeared here and is used with permission.

I have some very exciting news to share with you all!

My name is Eric The IT Guy and I am a recovering Systems Administrator! I have over 11 years of IT experience ranging from Systems Administration and Engineering to technical sales and community advocacy, most recently, as a Sales Solutions Architect at Red Hat.

My mission as the IT Guy is to fight against burnout and poor work life balance. My goal is to promote methodologies and communities around DevOps and Open Source as well asn an endless supply of fun gibberish along the way.
I have worked under all the cliche’d IT cultures – from nightmare on-calls to constant firefighting to teams that are as closed minded as the software they use. I’ve learned a lot from my more-than-a-decade of experience. I hope to share those stories and the lessons I learned with all of you to help make your lives and your organizations better.

Last but not least, we get to my Youtube Channel. I will be releasing periodic Vlogs there for more random content like an inside look at my experiences as a Solutions Architect.

I am excited to be joining such an awesome community. If you’d like to get in touch, just shoot an email over to Contact@Sudo.Show. You can follow me @ITGuyEric on Facebook, Twitter, LinkedIn, and Mastodon…just to name a few.

I can’t wait to get started, our first release is June 25th. I look forward to sharing my experiences with you and especially getting your feedback!

I spent over seven years in IT before I really started to understand the breadth of the industry. Technology gets a bad rap for being such a deep field but not necessarily a broad one. In fact, when I was attending college in 2009… Hold the phone… I graduated from DeVry University A DECADE ago! When did that happen!? Ugh, nothing like a personal revelation in the middle of a blog post. Any-who…the career advice I was given was there were two paths in front of me, eventually they would lead to: 1) becoming an architect, the system-designing ninja guru of a major enterprise or 2) becoming CIO of a major enterprise. Said another way, either you go the technical track or the manager track. It wasn’t ever really explained to me there were forks in those roads. Quite a few of them really! (In fact, a funny aside was that my the advisor for the first college I attended told me I wouldn’t ever be successful in IT because my higher math grades like Calculus, Trigonometry, etc. weren’t good enough. Jokes on them!)

While I am making light of a couple situations, these illustrate some very big issues in our culture, the corporate world, and our education system. (Disclaimer, I am not calling out DeVry in any sense. I loved my education and it set me up for great success. In fact, I was even crazy enough to go back and get a Masters from their graduate program.) In fact, any one person should only be limited by their own imagination or to quote the great philosopher, (Captain) Jack Sparrow: “The only rules that matter are these: what a man can do and what he can’t do.” Our rum-loving friend had a great insight. The more I learn about my career the more I realize I didn’t have a clue when I started out.

So, here’s the deal, I have been around the industry long enough to watch the shift from hardware to virtual machines to now cloud hosted workloads. I have worked within IT operations long enough to go from carrying a pager to two phones to an app-based on call rotation. I have seen the Internet go from a dial-up access to email and AIM to an essential element for virtually every industry. I have learned a thing or two along that journey and I really feel like I would be doing the industry a disservice to keep those lessons to myself. Heck, even writing that out made me think, “Hhmm, maybe I do know a couple of things!”

So, here is what I plan to bring your way. I want to address some issues that weigh on my mind: work/life balance, operational priorities, marketing buzzwords, career pathing, just to name a few. I want to share my experiences, make a few jokes, and deliver relevant news, content, and maybe a few tutorials along the way. I want to make my content available via blogs, vlogs, podcasts, conferences, whatever medium I need to use to help my fellow technologists find out where their passion and skills could best take them.

So…How about it? You ready?

Hey all! I am starting a new open source “project”: my next home! Please help me by making recommendations and helping me build the IT Guy’s dream house!

https://gitlab.com/itguyeric/smarthouse

Hey ya’ll! This has been a long time coming!

This IT Guy has a lot on his plate and figured it would be beneficial to chronicle some of my journey! Stay tuned because with a big conference this week and some big decisions upcoming for myself, there could be some great stuff here!