systemd seems to be a dividing force in the Linux community. There doesn’t seem to be a middle ground to systemd, polarizing opinions suggest that you must either love it or want to kill it with fire. I aim to provide a middle ground. First, let’s discuss the awful things about systemd.
The date is December 1st, 2016. Amazon announces an interesting new feature for CloudFront allowing running Lambda functions at CloudFront edge locations. This is a powerful addition to the AWS arsenal for running code in locations geographically closest to users. This feature is a “preview” feature, and it’s opt-in only.
After many years of internet content management dysfunction, I have finally begun to consolidate everything and solidify my approach to writing articles and publishing content. This site uses Jekyll as a content management system for hosting a static site, a modified version of Lanyon as a theme, and a fleet of other technologies to create a pretty comprehensive system. Since it’s all the rage to talk about how we each choose to do things, I’ll spend a moment to describe how all of this is setup.
Nobody ever said it’d be easy, but then again nobody ever said it’d be this hard.
The theory is simple enough, right? Put an ISO in your server, edit the Linux command-line, hit enter, and fifteen to thirty minutes later, you have a server running, configured just so.™ In reality, getting Kickstarts to actually work and to do what you need is pretty hard.
Ansible is awesome. You can automate all the things, which is a motto to live by.
Let’s automate sudoers permissions. This operation is one of the more dangerous operations you can run in automation,
right after dd or parted, with a little less risk. If sudoers gets screwed up, you won’t be able to gain root, and
that’s a perfect way to ruin an otherwise good day.