Devops

Welcome to the Great British Bake-Off, I mean Forgejo migration! I intended this post to be the whole story of how I took a week to migrate nearly 60 repositories to my own forge and set up CI/CD and dependency automation over it. The moment I started writing, I realized it’s going to be a long series. Hopefully you will stick along though. The Background I have always been a fan of self-hosting. Since the days of Debian Potato1, I have been fixated on the idea of setting up and managing my own servers and services. There is no surprise in my career choices after thinking about this. While that original server’s hard drive ate itself a long, long time ago, and I was forced to rebuild it all by hand over the weekend (tequila was involved somehow), I eventually learned how to automate everything. In general, version control was always at the center of my automations and scripts. ...

For those that don’t know I’m a Chef for a living. Not the kind that works with food but one that works with code. What you may not know is I’m a FreeBSD guy, or at least claim to be one. I’ve been building a new FreeBSD workstation and discovered that there is no chef-dk for FreeBSD. Building it isn’t bad, but there is a trick to it. So without further ado, here is building Chef-DK for FreeBSD 10.3 (and probably most >=10.0) ...

I, like many sysadmins, really want to monitor all the things I actually care about. Monitoring is in general hard. Not because it’s hard to set up, but it’s hard to get right. It’s really easy to monitor ALL THE THINGS and then just end up with pager fatigue. It’s all about figuring out what you need to know and when you need to know it. So in This case I Really Need to Know that My Machines Are Staying in compliance with Chef There was a few ways you can do this. The first thought I had was adding a hook into all of my runs and having them report in on failure. This is mostly because I’m always looking for another way to hack on Chef and work on my ruby. The big problem with this is: ...

It’s time for my monthly or so post! I wanted to go through and post about my OpenBSD firewall I built but that’s not 100%. Also I’m not ready to go on about anything amazing with puppet because without my lab being done puppet isn’t useful so lets go back to talking about my dev environment! I know Justin has been asking for this for a little while. Preface: Going “back” to Vim As a sysadmin at work I use vi a lot. Not even vim; vi. We have lots of unix boxes that default to vi as the installed editor and we don’t just go installing vim on everything. Personally I use vim a good amount on my machine since I spend a lot of command line time anyways. I know more than just a few of the commands but I really only consider myself a second or maybe third year vim user1 since I never used it full time to write code. I live the motion and use things like ci[ and C-v 5j x but I still fail to use multiple registers, buffers, or tabs… or even the leader commands. ...

Ok, so we have all our Nagios configs being sanitized and checked by Jenkins, why not Puppet: IT Automation Software for System Administrators? WHY NOT PUPPET!? A lot of this is going to be rehash of the PRIOR article but I wanted to document this out for later anyways since it’s slightly different. Step One: Assumptions and Layout I’m going to stop and assume we are well past the Jenkins setup phase. Please see the prior article for that… or better yet? make puppet do it for you. That’s what it is for. ...

Welcome to another edition on how to automate the hell out of your workflow. Preface One thing I have been addicted to since I learned it was source control. I don’t understand how some developers work without it… and I really don’t understand how any syadmins live without it. I have actually found it more useful as a sysadmin as a programmer, but only because at my day job I have used it in most of our major configs. Putting our 400+ file bind setup in subversion and using hooks to test and deploy our changes was not only a massive time saver but tail saver as well. ...