Thanks for the reply. You make a very valid point. However, part of my tasking is to document what I did to set up the server and provide sufficient information that the process can be repeated -- possibly by another group for another collection of machines.
I was hoping to reduce the server setup to a series of command line inputs and then preserve the whole thing in a Subversion repository. As I said, all the info I believe I neeed comes out in a report, but I would perfer to avoid the painful trial-and-error process of mapping the report to the command line, especially if someone else has already done this. I am an enthusiastic advocate of Avoiding the Re-Invention of the Wheel. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) ----- David Lee <[email protected]> wrote: > Dan White wrote: > > I am looking for a way to preserve a server configuration for disaster > > recovery purposes. > > > > Is there a way to "dump" the contents/configuration of a cobbler server > > such that it can be used as command line input to rebuild/duplicate the > > server ? > > > > The report output has all the necessary information, but it is not in the > > same form as it would be when being entered on the command line. > > > > Thanks. > > [...] > > We're new to cobbler, but are developing something resembling this > (using 2.0.11 at present). > > But first a little detour into how we might view Disaster Recovery (DR). > > <detour> > > People often think of DR as having a live service in one location and > something cold (possibly even powered off) and gathering dust until the > fateful day, in a different physical location. > > Certainly you need both locations! > > But I would suggest a possible variant view of "live service" for > consideration. Try the question: "When the fateful days arrives, how > confident am I that I can construct the service, in all its inevitable > complexity, on that cold system?" Or, even worse, include the thought > "...and I was caught in the disaster, therefore I am unavailable, and > someone else will have to restore...". > > Why not have your service running live, day-to-day, and distributed > across both locations. Then you KNOW that your DR location basically > works. There may still be other subtle trouble when the main site goes > away; this can only ever be verified by regular testing. But at least > you'll have some confidence that the copy of the server itself in the DR > location has been delivering live, good service. > > </detour> > > > So don't think in terms of setting up a cobbler server. Rather consider > setting up a cobbler service comprising two (or more) actual servers, > and day-by-day keeping those server components in step with each other, > and configuring clients to use them both. (Or if you have to have a > single IP, then regularly switch that day-by-day hosting-IP of your > service between the servers.) > > The basic technology to keep multiple cobbler servers in step is > "cobbler replicate". > > (And we're supplementing that with a "configuration management" tool > which itself configures and maintains those multiple cobbler servers. > But that detail is outside scope of the cobbler-specific question.) > > > Hope that helps. > > (Despite my appearing to give advice, I would also welcome advice as our > own group ourselves are relative newbies as we embarking on this.) > > -- > : David Lee > : ECMWF (Data Handling System) > : Shinfield Park > : Reading RG2 9AX > : Berkshire > : > : tel: +44-118-9499 362 > : email: [email protected] > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
