Configuration Management of root files system

Hi folks,

Looking to put my rfs under configuration management and am trying to figure out the best way to do that. I'd like to archive the entire rfs as I would source code for a project ... but CM tools would hammer the permissions/users/groups. Tarring the whole thing up is unattractive. It was also suggested that I write a script to restore permissions/users/groups.

How is this typically done? What other options are available and what are the repercussions of those options?

regards,

John Miller

Reply to
John Miller
Loading thread data ...

Not quite sure how much CM you want to do. If you just want the "current baseline" for your root file system, I suggest using System Imager

formatting link
which I've used to manage the master image of several clusters of systems.

The tools are pretty simple - an "image" of your system is a chroot'd directory tree under the image server. Whatever you apply to that tree will be downloaded to the next machine you build from it (or when you update a system). The script used to do the downloads also allows for some customization of each machine (e.g., host name). You can have several images on a single image server; we have a handful of system types we manage that way.

If you really want to keep multiple versions of the root file system, I am not aware of any good tools to do that. --Mark

Reply to
Mark H Johnson

Thanks for the feedback Mark.

Keeping multiple versions is what I'm really aiming for. I'm thinking that as we progress through development that the /etc files will undergo change while most others probably won't. I'm looking at the different products and seeing that BitKeeper perserves permissions. But I'm guessing that most of the linux developers out there just tar the entire thing up, and archive the tar ball. So, /etc files are managed by release, not by version. Perhaps I'm over estimating the need for CM on this issue. Please enlighten me.

thx

Reply to
John Miller

Hmm. I would guess that most developers keep track of their source files using CVS, BitKeeper, or some other tool. The usual sequence of ./config; make; ./install (or an RPM build / install) would then build and put the files in the right place and fix them up. However, we may be saying the same thing in different ways - where you say "the files are managed by release".

Like I said in my previous message - we only manage the root file system as the "current baseline" and don't care all that much about how we got to that point (other than having all the source necessary to get there). The source on the other hand is managed by version - with a few years of history to show the changes and who made them.

I haven't seen any one else speak up on this issue - perhaps they do the same.

--Mark

Reply to
Mark H Johnson

We do the same, more or less. I have a VMware session with the base OS I am building the root from and a set of scripts to build a RFS from that. The advantage of using a VMWare session are several, first you can install from any old distro, and second that you can do kernel builds in place and at the end of the job just tar up the VMware session for retrieval later if neccessary. That means that you always have a compatible environment and all the build tools no matter what you do with your desktop in the meantime. VMware seems to maintain compatibility fairly well, I still occasionally boot an old NT session I originally built with VMWare V2.? on my modern V4.5 release.

--
Trevor Barton
Reply to
Trevor Barton

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.