Linux4Bene wrote: > schreef Bob Proulx: > thanks for your reply and the time invested. Much appreciated. > It does indeed seem tricky unless you go the full monty and replace the > whole installation except for the special dirs like dev as you noted. > In my test, I didn't get any strange results in the end but I have > learned not to always trust what I see in IT. In the back of my mind, I > always suspect a problem popping up when the server is in production. Since /dev is dynamic anything done to it will evaporate after a reboot. After a reboot it will all be as if nothing had been overwritten there. If you get to the point of a reboot then there is nothing lingering afterward. You would be in the clear. I would still exclude it of course. The possibility of archiving /dev/mem for example makes me nervous. :-) > > But if you were overwriting *everything* on the system from the backup > > on one to the new system then after having done so then postfix would > > have been installed. Right? The binaries in /usr/sbin/postfix would > > The reason why postfix didn't want to start, even after untarring the > whole system was because exim was still running. After stopping exim, I > could start postfix without a hitch. Ah, yes, port 25 was still busy. You would have needed to kill exim first. Gotcha! > >> Might be better to start with: > >> Old server: dpkg --get-selections > packages > >> New server: dpkg --set-selections < packages > > > > Yes. That is what that was designed for along with some other things > > such as the dselect-upgrade and so forth. Those will be suggested and > > with identical versions (Stable, OldStable) they should be able to > > replicate the same packages installed on each machine. I wanted to add and emphasize for others that this doesn't work very wll when changing from one machine to a different system with a different version. Lots of packages change names and dependencies across major releases. It works fine when the version is identical. But across different releases there are a lot of packages that don't like up exactly from one version to the next. You are on the same version but I wanted to leave this comment in the archive for others reading it. > > And also because the user ids of system users and groups are dependent > > upon the order in which they are installed. When doing a system splat > > from one system on top of another all of /etc/passwd, group, shadow, > > gshadow being overwritten with new numbers for all of the system > > installed accounts. Of course that is matched by completely overwriting > > all of the files elsewhere too. And because it won't remove files on > > the new server that weren't on the old server and those files will > > become orphaned when /var/lib/dpkg is overwritten. As long as it is a > > complete overwrite of *everything* then it works. But for files either > > extra or missing it can cause problems. > > Indeed. And the users is one of the reasons why I did want to try a full > copy otherwise these subtleties could make the move harder. > Same with databases and the database users. > The fully copy means not having to worry with creating the users on the > system and database level. Then you will be set and good to go. > > Having said this it is something that gets done periodically and it does > > work. Google does upgrades across its data centers "one file at a time" > > using rsync. Pretty amazingly cool. > > Wow I didn't know that. They rsync their servers? That's binaries and > config I suppose? Every file. File by file. I liked this presentation and found it quite interesting. http://marc.merlins.org/perso/linux/post_2014-01-06_My-Live-Upgrading-Many-Thousands-of-Servers-ProdNG-talk-at-Linux_conf_au-2014.html Unfortunately the original paper is now 403 forbidden. I think that is likely a mistake somewhere. But the Internet Archive Wayback Machine has a copy if you want to browse it. https://web.archive.org/web/*/http://marc.merlins.org/linux/talks/ProdNG-LCA2014/Paper/ProdNG.pdf > > And then there is Guillem Jover's older 'debtakeover' project. > > http://www.hadrons.org/~guillem/debian/debtakeover/README > > The debtakeover project replaces a foreign non-Debian system (such as > > Red Hat or SuSE) with a Debian system in-place while the system is > > running. It basically replaces the system out from under itself with > > That's impressive. It sounds a bit like a Debian borg system :) As I recall one spot I don't think was as complete was the kernel both running and otherwise. I think debtakeover required that the new system run on the foreign system's kernel. Which is not always possible due to system version differences. I think that is more of a problem now than it was then. So for example replacing a RHEL 6 system with Jessie would fail because jessie binaries require a newer kernel than the default RHEL 6 kernel. But probably upgrading the kernel first with a native backport and then doing the debtakeover process would get past that problem. > When I rebooted the system, it failed because the UUID was still the UUID > of the main disk of the old system. Ah... Probably should 'grep -r $UUID /etc' for every mention of it. Are you using lvm or raid? If either of those then would probably want to *avoid* overwriting the /etc/lvm or /etc/mdadm directories. Both of those configs keep UUIDs in them. > I didn't change it manually but I did an upgrade-grub from a rescue > session from the Debian iso. The debian-installer in rescue mode tries to auto-assemble everything and avoids using UUIDs at all. Which is what is needed for a rescue system. One of the problems UUIDs solves also creates the problem of being rigid and inflexible by design. Rigid and inflexible doesn't react well to changes. Which is why we need a rescue system sometimes otherwise the system could rescue itself. Which used to be single user mode in the old days. > Afterwards, the system rebooted so I assumed the UUID was corrected > by running upgrade-grub? I will give that a definite maybe. I can't think through all of the possible cases. If it worked then I wouldn't try and would just keep going with it. > Bob, thanks for your thorough explanation & insight. It is an interesting problem. I am deep in the middle of installation and setup all of the time. Bob
Attachment:
signature.asc
Description: Digital signature