> > 3: When you first build the system, ghost/image the boot/root/usr > > (bru) drive onto a spare backup, verify the backup boots > > the machine the same as the main drive. > > 4: have the backup bru drive mailed to you, dupe it, and rsync the > > remote bru to your local copy whenever you make a change to > > the remote bru. > > This part tends to be problematic when the system is remote > and you need hands-on access for the install. It would be > much nicer to build locally and ship the initial drives. Build-local-and-ship > build-remote! Agreed! I'm not assuming the remote personnel are competent in Linux. I think you are. I suggest that "remote hosting security" howtos address the question of "what can we trust the remote people to do right?" We had one where the only thing we could trust the remote folks to do was cash a check. My comments were thinking "if you don't own the remote server hardware but can own/update identical disk drives" > > 5: In the event of fire, vandalism, or other urgent cause, your > > cluster can appear on a new server rapidly. Just FedEx > > ghosts of your locally stored bru drive rsynced from what were your > > remote machines, and (on similar hardware) they should turn-key boot and run. > > Try it - you won't like it. If the MAC addresses of the NICs > don't match what is configured, the network won't come up. > Have fun with that when you've broken the local > keyboard/monitor. I do try it (as INfrequently as possible), it's to address situations that nobody likes. Phone calls to establish IP/MAC numbers take care of most problems. When remote people can't be bothered to know how to spell IP, like on some offshore oil drilling rigs, we send out a disk-installer. I didn't point out the details of the unknown. Fire might or might not move the machines to a new ISP or IP; Vandalism ditto; "Other urgent causes" has (in my experience) been remote operators who could not be relied on and therefore a new remote host was necessary. In some cases the old IPs work, new MACs are needed, in other cases both change or neither changes. So editing of your rsync'd drives before shipping them to the (new?) ISP/IP site is maybe necessary. If you can trust your remote operators (more than I can) then remote KVM is an affordable risk. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**