A.P. Lawrence

A remote upgrade with rcp

When I do upgrades, I like to use new hardware. First, it's often a good time to bring in a new server: in the small business market, upgrades tend to be delayed for as long as possible, so the old OS is probably running on very old hardware too. Secondly, bringing in new hardware is less disruptive: we can often install the software and do any necessary testing without disturbing the users. This is particularly valuable when there is a lot happening: new OS, new or upgraded application software. It's nice to be able to find the bugs off-line.

Most of the time, I'm physically present on site for these changes. I'll use a Supertar for the data transfer, doing either an In Place Upgrade or (more usually) following my own advice on upgrades.

But that's not always convenient. Sometimes the client is too far away to make being on site sensible: it would just cost too much. I had one of these recently, and approached it as follows:

First, I shipped them a new machine loaded with SCO 5.0.7 and a Multitech RF560VPN router configured for their lan. I set it up with PPTP enabled and created an account that I could log into so that I could telnet into their old SCO 5.0.5 machine. I also set ssh port forwarding to take me to the new machine. They did already have support modems, but part of this upgrade's purpose was to get away from that and use ssh.

By the way, it would have been possible to move this system to Linux, also. The software was Synchronics Counterpoint replacing RealWorld. We could have run the Synchronics on Linux, but the customer also wanted to keep the old RealWorld software around for historical lookups, and that wouldn't have transferred as easily (if at all). If we were able to make it run, it would have had to be with Linux ABI, and with all things considered, it was decided just to use SCO 5.0.7.

I now had three ways to get to the remote network: modem, pptp and telnet, and ssh. As I had to rely upon non-technical people on-site, this wasn't at all overkill, but as it turned out, everything got hooked up completely and correctly. Of course I had to modem in to the "old" box set a default route pointing at the router before my telnet would work. I didn't need to set up resolv.conf for DNS name resolution as I had no need to go OUT from this machine; only needed to telnet in through the pptp tunnel (and even that would be temporary). I also set a default route on the new box, and did set resolv.conf there as I might need internet access to download patches, etc.

I started the upgrade by setting user equivalency with .rhosts and /etc/hosts.equiv and then transferring user accounts with "ap" (see Upgrades).

When establishing user equivalency for rsh rcp and rlogin remember that root plays by different rules: you must use a .rhosts file; hosts.equiv will NOT work for root.. Also note that entries in hosts.equiv or .rhosts must match the name that the other computer will be seen as- ping it to see for sure what name will be used. Use fully qualified names when necessary. Finally .rhosts MUST be owned by the user (root for root logins) and be chmod 700. If you are unsure how to set the name, use all possibilities:

# cat /.rhosts
localhost
192.168.2.13
oldcustsco
oldcustsco.cust.com

You only need one of these - which one depends upon how your DNS is set up and how you wrote /etc/hosts if that's being used.

All printers here were already on print servers, so I was also able to easily transfer those setups (see the "upgrades" article). That only left the Synchronics and RealWorld programs, and the user home directories. All of this was conveniently located under /u on the old machine. I used an "at" command to set a script to run after business hours that would do a recursive copy of /u to the new machine (rcp -r -p). I could have also done this using one of the Supertar backup programs or by other means. I then set my alarm a little early and went to bed.

Very early the next morning, I ssh'd back in and checked that all data was transferred successfully. I now needed to rearrange IP addresses so that the users would go to the new machine when they logged in this morning. To accomplish that, I first set the old machine to a completely different IP address, then reconfigured the new machine to have the old machines address. I set the original ip address of the new machine as an alias so that my ssh connection would still work.

That left just two remaining problems. Someone might log into the old machine by modem before I could get anyone on site to physically transfer the cables, and it was still remotely possibly that someone might walk into the server room and directly log in to the old box. To handle both situations was easy: all user profiles already did an "exec /usr/syn/syn" (Synchronics was already running on the old machine; we had done the initial install there, and RealWorld was accessed through a Synchronics menu). I simply replaced the contents of /usr/syn/syn with "rlogin newsco". As user equivalency was set, any user who did login by modem or otherwise managed to avoid my plans would just immediately transfer to the new box. For the root user, I just added a message that warned that they were on the "old" box.

That was it. The users arrived at work a few hours later, turned on their machines, and found themselves on the new system. Most of them probably didn't even know anything happened.

Psst - Wanna work for yourself?

Comments
RemoteUpgradeRcp :

"They did already have support modems, but part of this upgrade's purpose was to get away from that and use ssh."

Call me paranoid and/or old fashioned, but I still ship a diagnostic modem with each server I build. If a serious network-related problem arises and Internet connectivity is not available, I can still get in via the modem and (hopefully) fix things without having to drop everything and run to the client's site. That saves the client some money -- he's not paying for travel time -- and I get more stuff done because there's no dead time spent on the road. Of course, if there's Internet connectivity, ssh or telnet sure beat sending data via phone line.

BTW, Tony's narrative is a classic example of how good planning can make a complicated procedure go off without a hitch.

"The users arrived at work a few hours later, turned on their machines, and found themselves on the new system. Most of them probably didn't even know anything happened."

That has always been my litmus test for system migration: if the users don't notice anything different (other than improved performance, perhaps) then the migration was a success.

--BigDumbDinosaur


Add your comments

Why no "Digg this!" etc.?

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here