Hi Guys I've been thinking about this for a little while now and the 2 foreseeable options I see are below. It'll be obvious which I think is the better solution but feel free to comment on pro's and con's of each further.
1. Create some sort of script that picks up EVERY config file in a linux system and tar/gzip it up preserving directory structure, possibly with the addition of some encryption, in an openfiler system this includes XML files as well obviously. The script would also need to write version information into this archive so at the very least you know the version of openfiler these config files came from. This script is then run on the new/recovered system. If it is a new system you then have to resolve any version based dependencies that may have occurred, including format changes of the config files themselves. This may include the addition of new default options to config files or actual changing of keywords/options outright. This is obviously no easy task although it's obviously not impossible. 2. Store ALL configuration data in some central repository, weather this is a low overhead SQL DB like SQLite (http://www.sqlite.org/) or in a collection of XML files stored in a single directory it's doesn't matter. Then create a service that can take this info and generate full config files for the system and all it's services. This means transport of the system config is simpler as you don't have to worry about directory structure changing between version which would obviously mean config files were in the wrong place in option 1, here they would be created in the correct place by the backup/restore service since it is actually creating them from scratch. You could also have "template" XML files for the config files that are to be generated so that end users could change or add additional options to these generated files without having to actually edit the generated files themselves and worrying they will be overwritten. This also gives a nice way to reset a config back to defaults, have a command line option that will reset the DB to defaults and regenerate the config files. For an example of this in progress check out the rocks clustering project (http://www.rocksclusters.org/wordpress/). They have created this sort of system to generate preconfigured anaconda install points so all the cluster client nodes can be installed without intervention of any sort (rocks-dist is the utility to investigate). Overall both systems need to have options to backup/restore "hardware specific" options. Obviously if you're recovering from a failure you're doing so on the same hardware so you'd want to restore all network settings etc. On the other hand if you're upgrading to a new system you probably won't want to bring across network settings etc as you may very well be adding more NIC's for increased bandwidth etc. Dave > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Rafiu Fakunle > Sent: Wednesday, 27 September 2006 11:22 p.m. > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [OF-users] HOWTO: Upgrading from 2.1B1 to 2.1B2 > > Jason, > > > I'm sorry if I caused offense in the choice of my words. I > chose the > > word deliberatly because it does reflect my view and the > severity of > > the problem as I see it. > > > OK, here's the deal. Openfiler needs a facility whereby all > configuration settings can be backed up and restored at some > arbitrary point in the future. > It just so happens that such a mechanism will also apply in > migrating from 2.0 to 2.1. > > However there are many variables to take into account. So > while not insurmountable, it's also non-trivial to create a > tool that will backup/restore your configuration > satisfactorily enough that you won't have to resort to > Scotland's finest malts if it all goes pear-shaped. > > So anyone itching to move from 2.0 to 2.1 immediately, the > best advice is to backup, reinstall and reconfigure. If you > are happy/patient enough to wait for the backup/restore > functionality, great; it's going to come - sooner rather than later. > > > > But I did not (do not) want to cause offense by > > it. I apologise for any offense caused. > > > Buy me a glass of orange juice sometime and all is forgiven ;). > > > R. > > PS: thanks for the testing and bug reports. > > > ----- Original message ----- > > From: "Rafiu Fakunle" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [email protected] > > Date: Mon, 25 Sep 2006 11:53:47 +0100 (BST) > > Subject: Re: [OF-users] HOWTO: Upgrading from 2.1B1 to 2.1B2 > > > > Jason, > > > > ----- [EMAIL PROTECTED] wrote: > > > Will you be publishing how to upgrade from CentOS systems > to RPath? > > > > At some point yes. It may be as simple as backing up your data and > > reinstalling. > > > > > I find it an egregious omission that nothing has been said about > > this > > > so > > > far, > > > > egrigious: extraordinary in some bad way; glaring; flagrant: an > > egregious mistake; an egregious liar. > > > > > > There are only so many hours in a day. > > > > and I am worried that all your CentOS users are about to be left > > > out in the cold. > > > > You needn't worry about them, they're all big boys (and girls) :) > > > > > > R. > > _______________________________________________ > > Openfiler-users mailing list > > [email protected] > > https://lists.openfiler.com/mailman/listinfo/openfiler-users > > _______________________________________________ > Openfiler-users mailing list > [email protected] > https://lists.openfiler.com/mailman/listinfo/openfiler-users > _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users
