On Debian-derived systems like Ubuntu, it is possible to very closely duplicate the software installation from one machine to another by using the package management tools. Lets say that MachineA is the original server you want to mirror, and MachineB is the server that you want to become a mirror of MachineA. (All commands quoted here must be run as root
.)
First, make sure that the debconf-utils
package is installed on both MachineA and MachineB (run the following on both servers):
aptitude update && aptitude install debconf-utils
Next, on MachineA, take a copy of the current package state, and of the debconf database:
dpkg --get-selections > /root/dpkg-selections.txt
debconf-get-selections > /root/debconf-selections.txt
Copy the two files from MachineA to MachineB, e.g.:
scp /root/{dpkg,debconf}-selections.txt MachineB:
Now on MachineB, load the debconf selections file
debconf-set-selections /root/debconf-selections.txt
load the package selections file
dpkg --clear-selections && dpkg --set-selections < /root/dpkg-selections.txt
and finally, run the package manager to update your system's software installations
aptitude install
Now all that remains is to move over any needed config files from /etc
on MachineA to MachineB. This is best done manually, because there are certain files that need to be different on the two machines, even if they are to be mirrors of each other. For example, files like /etc/hostname
, /etc/network/interfaces
, and /etc/fstab
reflect things about their respective local systems that may (or must) be different on another machine. To generate a list of config files to consider copying from MachineA to MachineB, you can use rsync
in "dry run" mode, where nothing is actually copied, but the files that would have been copied are listed, e.g. (from MachineB):
rsync -rplgoDvn MachineA:/etc/ /etc
ADDENDUM
It is not unusual for warning and error messages to be generated by debconf-set-selections
. I have seen them many times myself, and I don't know why they occur, but I can't remember ever finding that they indicated an actual instance of a broken configuration.
If you are skeptical, and wish to allay your fears, you can verify whether all package configurations are okay by the following procedure: Create a list of all the packages for which warnings/errors were generated, and then manually run dpkg-reconfigure package
for each package in that list. If there are any genuine problems with a package, they should be exposed and/or repaired by the reconfigure operation.