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.
You’re definitely right about the examples being thin and sparse. Poking around hasn’t yet turned up a good guide to getting unmanaged entries under control, and the tutorial’s mention of /etc/motd doesn’t seem to explain *why* motd was chosen, or how to discern the other 300+ that need attention. That’s on a really bare install – my workstation claims 3065 unmanaged entries.
It’s early yet – I’ve only been poking at Bcfg2 for a couple of hours, but I did notice something funny in the Probes/current-kernel. Analyzing this is overkill, since the script isn’t in a tight loop, but it’s still interesting.
The current version of current-kernel is relying on an obsolete behavior of the 1970s Bourne shell, where it would directly open scripts and interpret the contents, later overtaken by the #! extension to exec() – since otherwise shell scripts always failed if exec() was called on them. Modern exec()s try to fallback on /bin/sh even now if the normal exec() approach fails, but it’s slower than the 1970s approach, since it means exec() has to spawn a /bin/sh to do the dirty work (slower than old shell just forking once). If you run strace on the shell calling current-kernel, you can see the clone(), the execve() implode, the shell opening and reading the script, another clone(), opening and reading the script again, and then execve() on /bin/uname. Messy:
echo `uname -r`
You can reduce that to clone(), execve(), open(), execve() – which amounts to one clone() fewer, with this:
exec uname -r
which executes faster than the antique approach.
The weirdest of all is that *this*, which would seem the fastest way, is actually slower than the one above in my tests, due to invoking the hack, I suspect.
exec uname -r
So, basically the contributor suggesting removing the #! line actually made it slower, at least on my box, and missed the more obvious optimization of converting the “echo `uname -r`” to just “exec uname -r”, which obviates the IPC.
Too bad this doesn’t work:
… but uname won’t ignore the extra pathname that would show up after -r, otherwise that *would* be the fastest.
Which guide are you following? The generic quickstart guide only talks about the motd example, but the platform-specific guides delve into more detail and also show how to get a machine completely managed. They can be found at http://docs.bcfg2.org/appendix/guides.html. Hopefully that helps.
Also, if you’re just getting started with Bcfg2, I would highly recommend the IRC channel. There are some really smart people who are usually extremely helpful.
Thanks, I’d found parts of that section a different way, but not the whole list.