Sorry that it has taken me so long to summarize; I've been busy (yeah, you've
heard it all before.) This was my original post:
>We have a network of about 30 machines, including Sun workstations, HP
>workstations, and some PC's and Mac's. We are planning to relocate; our
>network will be dismantled and driven to another site, and then reassembled.
>We have been tasked with writing certification procedures to verify that
>nothing "awful" happened during the move.
>Question 1: Have any of you out there dealt with this situation, and perhaps
> already have some certification procedures for HP workstations
> (HP 750's in particular) / Sun workstations (Sparc 10's, Sparc
> IPC's, Sun 4's, Sun 3's, Sparc 630MP)
> which verify that machines and/or network is working properly?
>Question 2: Can any of you offer me some ideas and insights as to types of
> things that I should include in the procedure? (such as
> diagnostics I should run to make sure the hardware is working
> properly, the network is working properly, etc.)
>I am particularly interested in ways to verify my Unix machines (but I won't
>shun any ideas offered on the PC's and Mac's ...) Also, I'm not in a position
>to buy lots of cool diagnostic tools; readily available/public domain stuff
>is how I need to go.
Thank you all for the many suggestions that I received! Here's a synopsis
of the ideas people sent me:
BEFORE THE MOVE:
- PLAN PLAN PLAN.
- An inventory is vital.
- Understand the primary work performed by the systems. "Verification" is
successfully executing these tasks.
- What does management expect this site to be doing? Get that in writing
before the move.
- Find out how much you're insured for, and buy additional insurance if you
think it's necessary.
- Make sure that you have the configuration of every machine documented.
Consider what you will do if a machine loses a root disk in transit.
- Identify the order in which the machines boot; NIS servers should boot before
NIS clients; make sure you have a DNS server.
- Make sure everything works before the move. Make sure that all the machines
will boot before the move.
- Know what errors show up in machines' startup logs before the move.
- Make sure all the machines have current backups. Backup EVERYTHING before
the move, and make double backups. Ensure that you have solid backups by
verifying with random recoveries.
- Label EVERYTHING, right down to the individual components.
- You'll probably won't be able to take the IP addresses with you. Consider
what will have to be done when the IP addresses are changed; IP changes
before moving will be easier to deal with than IP changes after the move.
- Try getting "sysinfo" from an ftp site near you. This reports memory, disk,
SCSI addresses, hostid, etc. and can help you compile the data and check it
before and after you move. The data should be identical before and after
the move, except perhaps the IP addresses.
- Use tripwire software from Purdue, and generate a list of checksums on
every file before the move; use this to verify that the files are all OK
after the move.
- Develop a checklist of major services: mail hub, DNS, database servers,
- For individual machines, work manually though a checklist: telnet, email,
printers, database processes, whatever.
- Run a baseline set of tasks before you move, and then run the same baseline
after you move.
DURING THE MOVE:
- Check the wrapping of all the equipment; make sure that the movers have
wrapped everything securely; double-wrap computers, place them in carts so
they don't get banged around in the truck. Wrap all the cables carefully
and keep them with their associated equipment.
- Move the backup media separately!
AFTER THE MOVE:
- For Sun equipment, from the boot prom "ok>" prompt, use EEPROM diagnostics.
prove-scsi-all: this give a readout of all scsi devices and whether
they are recognized and properly designated.
test-all: gives a wider band review of hardware and system
- Boot the machines into single-user mode first; run fsck on the hard drives
before going multi-user.
- Make sure the machines boot.
- Are there any faults?
- Check startup logs for errors; compare with the startup logs for the
machines before the move.
- For SunOS 4.x and 5.x, there are some diagnostics provided on-line.
- Change the IP addresses of the machines that were moved, reboot them, and
ensure that they are connected to the network. Basically, make sure every-
thing works after you plug it in.
- Make sure the machines can resolve hostnames via DNS or NIS.
- Check ftp throughput to ensure new network soundness.
- Can the machine be pinged to and from everywhere?
- Verify: Can you access any server?
- Use sar, ping, telnet, df, fsck, etc.
- Run xstm (X based diagnostics) for HP-UX. (Do a man xstm for the syntax
- Check all the services in the checklist that you made before the move.
- If you know what services that the Unix hosts should be providing, run SATAN
- Do an MD5 checksum list of all the files on the systems to verify file
- Use file verification tools from CERT to show that none of the files has
changed during the move. These tools are usually used for security, but
if the file isn't there or has changed in any way, they will catch it.
- Is the site doing what management wrote down that they wanted before the
- For PCs and Macs, use Norton's Utilities.
A special thanks to:
Terence Ee Buan Teck
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:55 CDT