Running the MOO: Bringing the Cows on Home

Growth and Development

When the MOO is up and running there are a few things to take care of. The wizards and administrators will, hopefully, take care of problems in the MOO itself, fixing errors and helping players. However, some things have to be done at the server side of the MOO such as making sure the MOO and its server is running, taking backups of the database for the MOO, and upgrading the server. The last depends on how much control you have over the server you are on.


The server security is an important issue for the MOO. That includes making sure the database files are unreadable for anyone who is not supposed to see them and to keep all the MOO files updated and as bug free as possible.

The database files should be protected from unauthorized access. The easiest way to do this is to make sure they are unreadable by anyone but the owner. Refer to your Unix man page about chmod for more information about how to set the permissions.

If someone can read the database files, they can access anything stored there, including personal mail, list mail, email addresses, and anything else that is read-protected within the MOO.

You should also ensure that the startup script, and possible shutdown script, are protected enough to prevent accidents. Do not let everyone call or use them.

Server Maintenance

At least one person must have access to the server in order to perform the server maintenance tasks. Even though backups can be automated (making a shell script that suspends and does a backup every now and then), it is always good to have someone take a look at the server processes, making sure they are running as they should. Furthermore, if something goes wrong with the MOO, the cause for the problem can often be found in the information provided by the log file the MOO maintains.

At times the manufacturer of the MOOserver you are running may develop newer versions, or fixes, to the version you are running. You then want to put those into the server you have, by changing the files in the servers code, compiling it again, and restarting the MOO with the new server.

Growth and Development

After a MOO is up and running for a while, the DB can grow quickly if you haven't anticipated expansion. The MOO must be allowed to grow and develop in order to stay healthy and interesting. However, if the MOO grows too quickly, and the server cannot handle the load requirements, the MOO will lag, making for a very unpleasant experience. As noted in the section on server requirements, you will want to make the best guestimate as to how large your MOO might get as people come online and develop. You will want to monitor the growth of the MOO, paying attention to the number of players and other objects, making necessary adjustments to policy if need be. It is always better to have a clear policy on things like quota usage from the outset, but if growth starts to spiral out of control, you will need to act quickly.


When the MOO is up and running you will always want to keep some backups of the MOO database. How many and how often you will take these backups depends on the stability of the server and the stability and rate of growth of the MOO. A very active MOO, comprised of numerous builders and programmers, will need to be backed up more often than a MOO which is fairly developed and sedentary. Backups are the safety net for the MOO. They are there in case something goes awry. A server crash might kill the MOO process before it can write its current database to file. Then it's good to be able to start from a previously saved copy. The MOO will keep one recent copy itself though. At each checkpoint, it dumps the database to file. So you can always use that to restart the MOO if the only problem is that the current database is lost. But there are other things that might destroy the current database as well as the last checkpoint. Sometimes wizards make serious programming errors which can destroy a vital part of the database. There may be the occasional strange bug stemming from an error in the operating system or the MOOserver. At times there are security holes in the data base which allow players to accidentally, or sometimes purposely, do things they are not normally permitted to do. These errors might have been in the system long enough to infest the more recent copies of the database you might have or the one made by the MOOserver itself. In these cases, you want to be able to go through your own backups to find the newest one without the error that shut the MOO down.

So how many backups should you keep? Well, that depends on how much diskspace you have and how unstable the server is. One scheme that will give you a reasonably good safety is:

Maintaining copies this way will ensure that you have a healthy copy at all times, allowing you to check a copy for the previous day, half a week ago, a week ago, a month ago, and a year ago. So you can look back, in longer periods the longer you get back, until you find a copy with the contents you want.

So a day in a year, say Jan. 1st:

  1. You will have a copy from the day before and the day before that.
  2. You will have one copy from half a week ago.
  3. You will have one copy from each week a month back.
  4. You will have one copy for each month half a year back.
  5. And, you will have a copy from a year back...and a year before that... all depending on how long your MOO has been running.
All this will add up to 13 copies for a year.

All this will of course take a lot of hard drive space, so you may want to delete some of the older copies. For instance, you will probably not need a copy from 11 months back. However, make sure you keep enough copies from the shortest time back, so that you will not lose to much if you have to use one of them to restart the MOO. To reduce this space demand a bit, these copies can be compressed with some compression program. Gzip works well on UNIX.

One thing you should also do is make sure some of the copies are not on the same file-system as the main database and copies. Sometimes a server and/or its file-system is totally destroyed. You want to be able to re-start your MOO with a fairly recent copy stored on another disk for these emergencies. The more recent the copy, the less work will have been lost.

Back to the implementation index.