Moving to a new site (by Rhyanna)

Moving to a new site (by Rhyanna) javelin Sat, 2007-11-03 13:34

Moving to a New Site (Rhyanna)
Sometimes it becomes necessary for a MUSH to move to a new site. These are some of the common reasons:

* The site gets taken offline because of host problems.
* The site provider graduates / flunks out / otherwise loses their account.
* The MUSH starts taking up too much memory, disk space, or CPU time.
* The sysadmin of the site realizes that a MUSH is being run without permission. (This is far more common than it ought to be. Always get permission before running a MUSH.)

In my time, I have participated in two atrociously handled moves, and one move that seems to have been relatively successful. Based on that experience, here are my tips for moving.

1. Move as seamlessly as possible. Ideally, you would @wall about the move at the old site, shut it down, ftp the database to the new site (where you've already compiled and tested the code), and restart, with a total elapsed time of ten minutes or less. This is feasible, if you have planned ahead, compiled and tested the code at the new site, and so forth.

One atrocious move of my experience involved having two copies of a MUSH up at different sites for a period of more than a week, each with a MOTD that said the other MUSH was the 'official' MUSH. Another atrocious move involved the MUSH being down at one site for two weeks before coming up at the new site.

In the successful move, on the other hand, we had been testing the new site for anomalies for a few days, and we had declared a time when the database would move from the old site to the new site. Even though the move didn't happen at exactly the time we had declared, because the new site was down for maintenance, the move was a success, in large part because we came as close as possible to always having one and only one 'official' version of the MUSH around.

2) Leave a forwarder on the old site and port. This is extremely important.

Unfortunately, a large number of players don't pay close attention to the MOTD or to any other announcement ahead of time. No matter how much publicity you try to create for a move, there will be a large number of players who don't know anything about it until they try to connect to the old site and fail. This is why you need a port forwarder on the old site.

Almost all of the reasons why a legitimately running MUSH would need to move can be worked around for a port forwarder:

* A port forwarder is very small (portmsg.c compiles to 32K on a SunOS 4.1.1 system) and takes an insignificant amount of CPU time.
* If the host computer itself is going down, it is often possible to coax your friendly neighborhood sysadmin to remap the old name to a new computer. This is fairly standard practice anyway, to keep e-mail from bouncing and so forth. If the name gets remapped, it's often possible to run the port forwarder on the new host.
* If you are losing your account on the site, you can often coax a friendly sysadmin or another person with an account on that host to run a port forwarder for you, because it is such a small program with low cost in resources.
* If the MUSH is being evicted because of its drain on system resources, a port forwarder should be acceptable as a non-draining alternative. If even a port forwarder is a significant drain on the system, it begs the question of how you ever got a MUSH to run on a Vic-20 in the first place.

All of these require some planning and require that you be on relatively good terms with your sysadmins. (It's worthwhile to be on good terms with your sysadmins even if you're not running a MUSH.) From this, a corollary follows:

3) Move well before it is absolutely necessary to move.

Many times, it is possible to have ample forewarning before a move is going to be required. A machine may fail with increasing frequency before it goes down for the last time. Graduation is usually not a surprise, either. A kindly sysadmin can tell you ahead of time when a MUSH is starting to consume too many resources. (Note: If you ask to be notified if the MUSH starts to become a drain on system resources when you get permission to run your MUSH, you can save yourself a world of grief.)

You need to run a port forwarder after the MUSH moves. You may need to do some negotiation to get the port forwarder to run. Therefore, you should move as soon as you have a new site upon which you have compiled and tested the code. You should not wait until the last minute; the more critical your need to move, the more trouble you will have moving without losing many of your players.