I’m a big fan of Devs having the skills and tools to help themselves. There are all kinds of benefits to this; Dev’s don’t have to wait for an “Ops guy” to be free to help them, the previously aforementioned “Ops guys” can concentrate on what they do best & lastly it can help give Devs a greater sense of accomplishment. This often falls back to Linux CLI skills which are not a Devs forte is most cases, so teaching them enough to get them unstuck is often a worthwhile endeavour.
This should go without saying but to be clear: the opinions expressed within this article are entirely my own and not those of my current employer (Sky Betting & Gaming) or any other persons (necessarily). I want to put my thoughts on DevOps out there. The immediate question that will hopefully spring to your mind is “What exactly do you mean by DevOps?”. If that was you, then give yourself a cookie.
As anyone that knows me can attest I’m a big proponent of automation and of Puppet in particular, and as Justin Arbuckle (@dromologue) said: “Compliance without automation is fiction”. For me the two go hand in hand and Puppet can and should be used to increase the security of the boxes it manages. Now conveniently enough I recently created a module for managing the Linux Auditing daemon. After releasing this someone asked if I’d be writing something up about rules people should be looking at when using Auditd, now what a good idea!
Just a quick blog post today. I am currently looking at Puppet usage inside of AWS and wanted to make the entire process as automated as possible so here’s what I came up with. Firstly use the puppetlabs/aws module to define your environment, you can use Hiera to make life easier in the case that you want to create separate VPCs that are functionally identical but with small differences. This works quite nicely but my question then became; OK so it spun up some EC2 instances for me, what about configuring them?
For your really secure boxes multi-factor authentication is probably a really good idea. So lets take a look at setting this up using the Google Authenticator (using One Time Passwords) on CentOS 7 to add a second level of authentication. So first of all lets install all the libraries and programs we need on our box to get this set-up: [root@centos7 ~]# yum -y install automake autoconf gcc libtool pam-devel git qrencode ntp Sadly the pam module itself is no longer provided in EPEL for EL7 (a very annoying trend I’ve noticed) so we need to grab it from GitHub and while we’re at it cd into the directory: [root@centos7 ~]# git clone https://github.com/google/google-authenticator.git Cloning into 'google-authenticator'...
In this post I’m going to cover the set-up of a truly great clustered filesystem; GFS2. GFS2 is developed by the venerable Red Hat and has been supported in Linux since kernel version 2.6.19, so unless your distro compiles it out you should be able to take advantage if it. In this post I’m going to take 3 CentOS 7 boxes and use GFS2 to safely share a filesystem between them.