How about option #3: Build a hard drive (or hard drive set) locally for the system and ship them to be installed?
I think that would give you the best of both of your previous options. Granted, you'd have to go through export compliance stuff and all that, but it might be worth the extra hassle. Just a thought. Ben Collin Starkweather wrote: > I have a server that is in need of a significant update, but it's > proving a challenge. I have a big picture question, then provide some > details below. > > (I originally thought the gentoo-admin list would be the best place to > ask this, but based on the stats, it seems to be relatively inactive. > Let me know if there is a better list to ask the question on.) > > Please excuse the length of the question, but as you can see, there are > a variety of variables in play. > > The Big Picture > --------------- > > The server has not been updated since late 2005 or so. It just runs > Apache, mod_perl, and an application server. So far, it has just hummed > along doing its work without complaint, solid as a rock, which is why no > one has bothered with it. > > As you doubtless know, if you miss a couple of upgrade cycles with > Gentoo, there can be (and has been) breakage when trying to emerge -u > world. > > There are two identical drives, and I've mirrored (manually, not RAID) > one onto the other. > > The challenge is that the box is in the U.S. and I live in China. There > is no one there who can administer it; however, if something goes really > wrong, someone can just swap the drives and reboot. The key factor is > that I want this to be as low-risk as possible since swapping the drives > is about the extent of on-site support available. > > The big picture question: Would it (1) be simpler and easier to rebuild > from scratch on the redundant drive, or (2) is it simpler and easier to > deal with the current issues updating from 2005.0 and a 2.4.x kernel? > > The Details > ----------- > > Option (1): Rebuilding on the Redundant Drive > > Pros -- It seems this would be the easiest way to do things, and I get a > fresh kernel and build. > > Cons -- If I rebuild on the redundant drive, I lose the ability to swap > drives if there is breakage. Also, the application server (Apache > Pagekit) is solid as a rock, but a real bitch to configure. Last time I > tried to upgrade Pagekit, due to Apache versioning issues, configuration > changes, etc., it took me a full weekend. Not fun. > > Option (2): Upgrading from 2005.0 > > Pros -- Perhaps less risky (advice on this would be appreciated!) and I > maintain another drive I can use to compare configurations, selectively > roll things back, etc. > > Cons -- The gory details. When I did an emerge --sync, the > /etc/make.profile symlink broke. It used to point at > > /usr/portage/profiles/default-linux/x86/no-nptl/2.4 > > which no longer exists, I suppose since the 2.4.x kernels seem to no > longer be supported. > > So the questions that arise are: > > 1) Would it be less risky to upgrade from 2005.0 to 2007.0 than rebuild > from scratch on the redundant drive? > 2) What is no-nptl? I don't know why the old portage profile was > /usr/portage/.../no-nptl. It seems to have something to do with > glibc-2.4. Do I still need it? Or can I just point /etc/make.profile > at /usr/portage/.../2007.0? > 3) I pointed /etc/make.profile at /usr/portage/.../2007.0, and tried > emerge -pu world. I was told that mail-mta/qmail no longer existed and > is required by sudo (?!?) which is required by libapreq2. Perhaps > mail-mta/netqmail is the new qmail? Anyway, this gives me the > impression that there are deep dependencies that may have changed > significantly. Is this what you would (subjectively) characterize as a > bad sign? > 4) What would be the best order of operations? emerge -u world, then > update the kernel, or update the kernel, then emerge -u world? > 5) 2008.0 is due on March 17. Is it worthwhile putting off the upgrade > for 2008.0? I wouldn't want to deal with two difficult upgrades if > there is breakage between 2007.0 and 2008.0. > > Thanks in advance, > > -Collin > -- [email protected] mailing list
