Re: Windows Server to Debian migration
On Sat, Sep 03, 2005 at 02:12:04PM -0400, Roberto C. Sanchez wrote:
> On Sat, Sep 03, 2005 at 02:02:09PM -0400, Joseph H. Fry wrote:
> > Thanks to all of you who have responded so far!
> > Right now I am trying to decide how I will migrate from a test server I will
> > be setting up to to the production server. I always work a project
> > backwards when planning, that way I always know where I'm going.
> There are certainly worse ways to plan :-)
> > If I used dd to copy the disks, and assuming I didn't compile a custom
> > kernel, should the changes in hardware really matter. Both machines will
> > use smp kernels, so essentially wouldn't the new hardware be detected and
> > just work?
> If you have discover and such running then you are probably OK. The
> problem is if you have certain kernel modules loading up and others not
> loading based on your test server hardware, moving to the new server
> could prove troublsome.
> > If not, I figure once I have the test server configured and ready for the
> > real thing I can use
> > dpkg --get-selections > file
> > and
> > dpkg --get-selections < file
> > To replicate the installed packages on the production server. But that
> > done, how do I replicate the configuration of those packages between
> > machines. I simply need the configuration of all the packages, the
> > structure of my OpenLDAP install, apache, ftp, samba, and any other
> > customizations I make. Any accounts and data I created on the test server
> > can be recreated.
> If you are installing exactly the same packages and all other things are
> the same (except for hardware), you can safely copy most of /etc
> (except for things like /etc/modules, /etc/hdaparm.conf, and so on).
> > Is there a tool or other simple way to do this. Or should I just keep a log
> > of every file I modify and just copy those files.
> Unfortunately, there are no tools of which I am aware to do this.
Keeping a log of all the files you change? That's what systems like
CVS are good for.
Check *all* of your configuration files into CVS
*immediately* after you have installed your Debian system and gotten the
hardware working. That's your vendor branch. Then start a new CVS
branch, install all your applications, and check the configuration
of your production system into the new branch CVS.
D make sure you check in the entire configuration. Some applications
may stick files in out-of-the-way places. Some applications may have
things you consider configuration but they, and Debian, consider
application data. You really have to get *all* of that stuff.
When you set up your new hardware, check its configuration after
Debian installation into your vendor branch, and then merge the changes.
THis should give you a pretty good approximation to what you need.
Can't tell for sure whether this will work automatically, and there
are bound to be glitches, but this is the way to track changes.
In fact I'm still puzzled why Debian doesn't check /etc, at least, into
CVS by default. It seems it would be a great way to back out of
There are other revision control systems you could use instead
of CVS, such as subversion. I like monotone because it's totally
distributed and knows how to deal with renamed files and the like,
but it's still a bit buggy and (in my opinion) not really ready for
reliable production use yet. If you like it and use it, you might
find it advisable to use another system as well in case of trouble.
> > Any advice would be appreciated. I really don't want to do this piecemeal
> > as suggested, mostly because I think the first thing I would need to set up
> > is ldap since other services may need to be configured to authenticate
> > against it... and I'm not sure I want to try and figure out how to integrate
> > ldap with a windows AD server for authentication.
> > Does anyone have any experience replicating a Debian install from one
> > machine to a entirely different machine? I'm sure it's been done, but what
> > is the easiest way to maintain package configuration and account for the
> > enormous changes in hardware?
> Personally, I have done this, even going to a completely different CPU
> (PPro to Via Eden C3), which required, among other things, a new kernel,
> and taking care to change or remove things like the hdparm
> configuration, the lm_sensors alarm setting and the ntp drift data.
> Roberto C. Sanchez