Codex.org

RightScale provides repositories to use for doing system updates and patches to your machines, but by default, they are only used for installing applications via RightScripts or Chef Scripts. It is up to you to be responsible for patching your servers and ensuring you do not have any vulnerabilities open for the world to exploit. Based on the way that RightScale has setup the repositories, you have to modify where your system is looking in order to install these updates.

To this affect, I wrote a RightScript a while back that can be used to change the default repo that is used to pull updates from. The script has been working great for the past few months, but as more and more updates come out, the delay in booting becomes more and more pronounced. If you are not using dynamic server arrays, this is not an issue. So, it take 20 minutes to boot the server instead of 10. At least the system is patched.

But, if you are using server arrays, and have to handle surges in traffic or load, then the time a server takes to come online is very important. A difference of 10 minutes can be immense. So what can be done to alleviate this problem? We have take to using two various methods to reduce the time that updates take to install on our servers.

I recently started working with RightScale to manage servers in various cloud environments. The servers that I am working with are in the Amazon EC2 cloud, but RightScale provides an interface to manages servers in multiple cloud spaces.

The underlying operating system for the servers that I am managing are running CentOS. While I prefer RedHat, CentOS is fine. I understand the reason for going with both, and when cost is an issue CentOS commonly wins out. The version is CentOS version 5.4.

The problem is that the servers are not getting updates. Based on the RightScale blog, you should be able to choose a RightScale supported frozen image of the CentOS mirrors from any given day, and they will have the most up to date patches to that day. As the servers do not maintain state between reboots, this means you can set the repo for a specific date, and the patches would be consistent for multiple machines no matter when they were booted.

As I stated earlier, the first 3 days of the Red Hat rapid track training went by in a blur. The amount of information covered was more than I believe a lot of people could absorb in the short time frame. There were a number of people at the training claiming that they were going to fail the certification exam at the end of the week.

Day 4.

The first half of the day was spent finishing the course material. In a strange twist, the stuff that we covered on the last day was some of the easiest items that we had covered all week. During the training I was able to pull out my laptop and answer a few emails that needed seeing to. While the material covered in the last day did not seem that important it is where I spent the second half of the day that made all the difference.

The first 3 days of the Red Hat Rapid Track course have been fairly intense. The main reason for this is the shear amount of data that is covered in three days. I have taken other training courses that take 2 days before you even get into the training material. That would not be the case when it comes to the Red Hat rapid track course.

For starters, I am taking the course at a local Red Hat approved training facility. The location is in a part of Atlanta that is probably convenient to the largest number of people around town. If you know the Atlanta area, then it is just north of I-285 off on GA-400. For me it is a bit of a trek, but all in all it has not been a bad commute. If I was doing my normal work hours and not 9 to 5 it would be even better. The facility is clean, and the coffee is much better than what we have at my regular office.

This week I am going to the Red Hat RHCE Rapid Track Course with RHCSA and RHCE Exams included. In the past I have been an RHCE (Red Hat Certified Engineer), but it expired a few years back. As the exam costs several hundred dollars, and it was not a priority, I never went and took the exam again. Now the opportunity has arisen for me not only to take the RHCE exam, but the week long Rapid Track course as well.

It should be interesting to see how the training stacks up to some of the other training that I have had. If it compares to the training that I had for JBoss, then I will be pleasantly surprised. Though, if I remember properly, that training did have areas where it could have been improved.

This is the course description as pulled off of the Red Hat website, at the time of me taking the class.