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 David.Lee@ecmwf.int 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: david.lee@ecmwf.int _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler