APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

A remote upgrade with rcp

© August 2004 Tony Lawrence

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

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.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> A remote upgrade with rcp

1 comment

Inexpensive and informative Apple related e-books:

Take Control of the Mac Command Line with Terminal, Second Edition

Photos: A Take Control Crash Course

Are Your Bits Flipped?

Sierra: A Take Control Crash Course

Take Control of IOS 11

More Articles by © Tony Lawrence

"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.



Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

All this modern technology just makes people try to do everything at once. (Bill Watterson)

Linux posts

Troubleshooting posts

This post tagged:

Remote Access


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode