October 2010 – Sol's blog

Bcfg2 example repository

Oct 262010

I have just started creating a new sample Bcfg2 repository on github. This post details the strategy used in this repository in order to make it easy to pull in updates and merge them seamlessly with your running Bcfg2 instance.

The primary goal for this repository is to be nondestructive when someone tries to pull in the changes from upstream. However, in order to do this, there is a slightly more complicated repository structure involved.

The first thing you’ll probably want to do is grab a copy of the repository:

git clone git://github.com/solj/bcfg2-repo.git

As you inspect the repository, you’ll notice that I have tried to make use of Xinclude in order to prevent overwriting custom repository files. The idea is that you will have 3 separate files (file.xml, upstreamfile.xml, and localfile.xml). The basic format for file.xml will be a comment with information about the purpose of the file. Then it will xinclude localfile.xml and have a comment containing the xinclude for upstreamfile.xml. The reasoning behind this is that you will most often have slight changes in your local repository from what is contained upstream. Therefore, you will most likely populate localfile.xml and merge in any changes from upstreamfile.xml manually.

This appears to be working out well so far (although I haven’t really added enough content yet). I am also considering adding paths to default configuration files (e.g. ssh). I am thinking about populating them using group-specific files so that they can be overridden by adding a group file with a higher priority. I am also considering possibly adding a separate layout under Cfg/TCheetah/TGenshi and using altsrc to bind the entries from the Bundles.

I’m hoping this all works out and any comments/criticisms are welcome. I know that the useful examples out there are sparse and widespread. I’m hoping that we can get something together which allows people to collaborate on useful configurations easily so that the initial barrier to using Bcfg2 is decreased.

Typing less with xargs

Linux 2 Responses »

Oct 102010

The xargs page on wikipedia talks mostly about the benefits of using it when running tasks on large lists. However, I have found it to be useful in other situations as well.

Oftentimes I am tasked with suspending accounts at work due to CPU (over)use. During this process, I frequently come across accounts which are processing Awstats statistics for some excessive number of domains (as this is the default setting in CPanel). This is normally because the number of domains for a particular user is something > 1500. In order to kill off the statistics processing, I usually just find and kill all the processes running for that user. I used to use the following to do that:

for p in `ps aux | grep ^user | awk '{print $2}'`; do kill $p; done

This is actually pretty simple and works quite well. However, it normally requires use of the Home/End keys along with ‘`’ because it’s usually after I get the process listing that I realize awstats is running. This is where xargs comes in. Usually the command typed just before the above is this:

ps aux | grep ^user

From there, it would be nice to awk out the process ids and pipe them to kill. Here is some sample output of what I’m talking about:

$ ps aux | grep ^solj | awk '{print $2}' 2190 2205 2237 2240

So, the result is simply a newline-delimited listing of the various process ids running for a particular user. Note that because I am on Linux, awk is actually gawk so I don’t have to worry about the newline separation being an issue. Therefore, I finally came up with the following elegant solution to my problem:

ps aux | grep ^solj | awk '{print $2}' | xargs kill

As you can see, this makes it extremely simple to go from the previous command to the one needed to kill off all the user’s processes. No special characters modifications at the beginning of the line are necessary. While this may seem like a miniscule amount of time saved, it actually adds up quite a bit with the number of suspensions made in this manner :-). I look forward to using xargs for inode abuse as well, but we’ll save that for another post…