MOO-Cows FAQ Ken Fox Last updated Monday, September 01, 1997 The "MOO Frequently Asked Question List" is maintained by Ken Fox (fox@ccs.neu.edu). Direct all questions or comments concerning this FAQ to him. Submissions and questions are welcome and appreciated. Ken Fox makes no warranty regarding the fitness of any of the informa- tion in this FAQ. ______________________________________________________________________ Table of Contents: 1. Server Related 1.1. What is a MOO? 1.2. Who invented MOO? 1.3. What are the minimum requirements for running a MOO? 1.4. Location of LambdaMOO server source. 1.5. Location of core databases. 1.6. Non-UNIX MOO ports. 1.7. What kind of security risk is running a MOO server? 1.8. When is the next release due out? 1.9. Is diskbased MOO going to be part of the next release? 1.10. Why won't my MOO send email with new character's passwords? 1.11. How does the MOO pick a verb to run when someone types a command? 2. Database and Programming 2.1. Where can I get the Programmer's Manual? 2.2. Is there a way to incorporate new features of LambdaCore into my MOO's DB? 2.3. Objects like $room and $player are part of the `core' of the MOO. How do I add new ones? 2.4. $spell is HUGE. How can I recycle it without running out of ticks or seconds? 2.5. How do I do execute a verb automatically each time the server starts? 2.6. How can I make an object in a room listen to everything that's being said? 2.7. My MOO checkpoints every hour. I want to change this but I don't know where to look. 3. Miscellaneous 3.1. Where can I find the answer to... 3.2. I'm new to UNIX, and I need to .. 3.3. I want to port something from one MOO to another. Who do I ask for permission? 3.4. What are some good clients to use with MOO? 3.5. How do I change my MOO password? I've forgotten or lost the password to #2! How do I log into my MOO? 3.6. How do I subscribe to/unsubscribe from this list? 3.7. How can I obtain additional copies of this list? 4. Other Resources 4.1. Information 4.2. Archives ______________________________________________________________________ 1. Server Related 1.1. What is a MOO? MOO stands for MUD, Object Oriented. The Programmer's Manual introduction describes the LambdaMOO server, which is the most commonly used program to run MOOs. The MUD FAQ has a definition of MUD . 1.2. Who invented MOO? Stephen White (ghond) wrote the first MOO server. Pavel Curtis took the basic design, language, and code, fixed bugs and added features to release the first LambdaMOO version. He maintained the server for several years. The MOO server is currently maintained by Erik Ostrom (eostrom@research.att.com). 1.3. What are the minimum requirements for running a MOO? The LambdaCore database is approximately 2 megabytes in size. The source and executable for MOO will likely occupy another 1-2 Megs. In its current state, MOO resides entirely in resident memory when running. The process size is going to be roughly 2-3 times the size of the database file on disk. Your mileage will vary from system to system. 1.4. Location of LambdaMOO server source. The current LambdaMOO server source is at ftp://ftp.research.att.com/dist/eostrom/MOO/. The file LambdaMOO-X.Y.Z.tar.{Z,gz} (for a current server version of X.Y.Z) is a compressed tar file containing the complete source code, installation instructions, and a copy of the `Minimal' LambdaMOO database. MOO has been compiled and run successfully on several different operating systems including AIX, BSD UNIX, SunOS 4.x, Linux, Sys V R4, Ultrix, OSF, FreeBSD386, Solaris, and NeXT. Major MOOs are currently running on almost all of them. In addition to the server, you will need a core database. A core database provides functionality augmenting that of the server. Every MOO needs to start from some kind of core database. 1.5. Location of core databases. Until recently, the only core database available was LambdaCore. LambdaCore is still what most people use. You can get it from the same directory that the MOO source is available in. The file `LambdaCore-DDMMMYY.db' (for some date DDMMMYY) is a LambdaMOO database file containing the `core' of the running LambdaMOO database as of the specified date. This is almost certainly the easiest place for you to start from in creating your own MOO, since this includes such useful things as the various generics (room, player, exit, thing, container, note, etc.), the MOO text editors, the MOO mail system, etc. Core databases available: LambdaCore The original. Retrieve it from ftp://ftp.lambda.moo.mud.org/MOO/LambdaCore-latest.db. To contact the maintainers, send mail to *core-db-issues (if you have a character) or *wizard-list (as a guest) on LambdaMOO lambda.moo.mud.org 8888. JHCore A LambdaCore based db that adds significant enhancements. It features a hypertext help system, administration groups, MCP fancy client support, enhanced English presentation tools, and lots of other features. See Why JHCore for more information about the enhancements. JHCore is available from JHM's FTP site . Connect to JHM jhm.moo.mud.org 1709 and send mail to *jhcore. 1.6. Non-UNIX MOO ports. There are some non-UNIX ports of MOO, including ports to MacOS and Win32 (Win95/WinNT). See the resources section for the latest list. 1.7. What kind of security risk is running a MOO server? (Most of the facts for the below answer come from thread on MOO-Cows about this subject. Most of the text, too. Thanks to Jay Carlson (nop@nop.com) and Ian Macintosh (siman@ihug.co.nz).) Disclaimer: Everything said here is an identification of a risk I am aware of. I am not a security expert. There may be other risks or the risks I mention below may be of other forms. As with any other answer in this FAQ, I welcome submissions on this subject. One of the first things to keep in mind with computer security is ``what are we trying to protect from whom?''. The threat that the unmodified MOO server poses to the server machine is limited to denial of service attacks. A MOO programmer could use all the memory, CPU, or disk on the partition that MOO is dumping to. The server itself provides no access to the filesystem (though there are patches that do) or other operating system services. If you have OUTBOUND_NETWORK turned on, there are a few threats to machines on your local net if they use some sort of ill-configured IP- address-based trust mechanism. Only sites that rely on the dubious security of address-based trust will need to worry about this. Your network admins will know if they have such an assumption built into your network, and can remedy this by taking your server machine out of the trust list. Now that MOO can speak binary data, the number of services you could potentially attack through it has increased. I still do not think it is a problem unless you use address-based authentication for things. If you have OUTBOUND_NETWORK turned on, your machine could be a threat to the Internet as a whole by laundering connections---an attacker connects to your server, and then connects through it to the machine they're really after, to make tracing their connections more difficult. The chance of this is vanishingly small; there are far more convenient anonymous sites out there that are perfectly able to launder connections for the cracker community. By running any sort of visible and popular network service, you become more of a target for conventional cracking attacks. This risk is not exclusive to MOO; hosting a popular web page will make it more attractive for people to attack you. Depending on your level of visibility, you may want to tighten up general security on your machine or site. Some organizations have other concerns. A MOO server may allow organizational mapping, or accidental disclosure of proprietary information, or whatever. If you're a company that has issues like this, you already understand these things or have people at your site that do. Go talk to them. Feel free to ask them how the MOO server is more dangerous than existing communications mechanisms such as electronic mail or the telephone. 1.8. When is the next release due out? It is unpredictable when each new version of the server will be released. The latest version of the server is 1.8.0p6. This is the first release by Erik. 1.8.0p6 is available at ftp://ftp.research.att.com/dist/eostrom/MOO/. 1.9. Is diskbased MOO going to be part of the next release? No. No diskbased version of MOO is planned. (The following from a recent post to MOO-Cows from Roger Crew ( rfc@microsoft.com).) Since most machines these days use virtual memory and disk I/O caches, the line between "running off the disk" and "running entirely in RAM" is rather severely blurred. It is the fundamental nature of virtual memory that, once you request more memory than you physically have, you are, to some extent, running off the disk whether you like it or (more likely) not. Conversely, a program that "runs entirely off the disk" may yet be running mostly in memory if its pattern of disk accesses is suffiently I/O-cache-friendly (i.e., not trying to touch so much of the disk at once that it blows out the cache). The real issues as I see them are: (1) performance That is, what performance win is to be had by having the server take more explicit control over the disk One would think that since the server has some concept of how often various objects/slots are used, it could implement its own swapping with somewhat more intelligence. Then again, given how generic the MOO language is and how much work has gone in over the years into OS paging algorithms and the fact that the OS-level stuff has a fair amount of hardware support, even having a server that will do as good a swapping job as the OS would have done will be something of a challenge. It may be that the effort would be better spent restructuring the memory layout of MOO code/data so as to be more paging-friendly, thus working with what the OS has already provided rather than trying to reinvent/duplicate it. (2) how best to achieve persistence The ideal here is that the state of the world should be continually saved in as low-overhead a manner as possible and that restoring this state (i.e., when your server crashes) should go as quickly as possible. I think there's a fairly strong consensus that forking every n hours to do a disk dump is not really the best way to do a checkpoint. I also suspect that this, fast incremental checkpointing and fast restore/startup, is really what people are concerned about when they say they want a "disk-based" server. The actual implementation that achieves this is immaterial. 1.10. Why won't my MOO send email with new character's passwords? Using outbound mail requires that the moo be able to open up network connections. This is a compile time option in the options.h file. There is a line that looks like this: /* #define OUTBOUND_NETWORK */ /* and */ are C comment markers so define is commented out. If the MOO server is compiled without OUTBOUND_NETWORK being defined, then calls to open_network_connection() will fail with E_PERM. Since outbound mail depends on open_network_connection(), outbound mail doesn't work without OUTBOUND_NETWORK. To enable outbound network connections, recompile the MOO server after editing options.h so it includes the line: #define OUTBOUND_NETWORK See also help open_network_connection() in LambdaCore for more information on open_network_connection and the README file in the MOO distribution for more info on compiling the MOO. It is a good idea to look over options.h as there are several important options set there. Andy Bakun (abakun@rci.ripco.com) 1.11. How does the MOO pick a verb to run when someone types a com- mand? See the LambdaMOO Programmer's Manual: The Built-in Command Parser. 2. Database and Programming 2.1. Where can I get the Programmer's Manual? The LambdaMOO Programmer's Manual is a complete reference for all database-independent aspects of the LambdaMOO system, including the programming language, built-in functions, and command parser. The Programmer's Manual is available at ftp://ftp.research.att.com/dist/eostrom/MOO The file name is `ProgrammersManual.*' where `*' is the format tag. It is available in DVI, PostScript, TeXInfo, and plain text formats. 2.2. Is there a way to incorporate new features of LambdaCore into my MOO's DB? There is no easy way to merge databases. The easiest thing to do is just snag the code from LambdaMOO or somewhere and build/rebuild the objects by hand. (For information on how to do so, see `help @dump' on LambdaMOO.) 2.3. Objects like $room and $player are part of the `core' of the MOO. How do I add new ones? As documented in the Programmer's Manual Getting and Setting the Values of Properties, $name refers to the property on the system object (#0) named "name". Therefore, object references such as `$player' are created by adding a property of that name to the system object (#0) and storing the appropriate object's number in that property. For example, referencing $room is the same as referencing #0.room. When the verb @make-core-database is run, it searches the system object for these links in order to determine which objects belong in the core. Newer releases of the LambdaMOO core include the wizard verb @corify which will add the specified object to the core in the manner illustrated as well as checking additional features such as an `init_for_core' verb being programmed on the object. 2.4. $spell is HUGE. How can I recycle it without running out of ticks or seconds? Mr. Spell is so large that he can't be deleted in the conventional manner. What you need to do is this: ;recycle($spell) @rmprop #0.spell This leaves a hole in the database however. You can easily live with it but if you find that you can't, just fill it by doing this: ;$recycler:_recycle(renumber(create(#1))); ;reset_max_object() Another option is to call $spell:clearall() and recycle the object as usual. This takes longer, but it does leave you the option of using $spell later, or with a smaller dictionary (by not recycling it). $spell without the dictionary is not very big. 2.5. How do I do execute a verb automatically each time the server starts? When the server starts, it calls the verb #0:server_started. Create or alter that verb to have it call the verb you want to execute. If a task has suspended or forked, and its execution is still pending when the server checkpoints or is shutdown, that task is saved along with the rest of the database. Thus, when the server is restarted, that task will be resumed. 2.6. How can I make an object in a room listen to everything that's being said? When something is said in a room, each object in that room is sent that text via the verb tell. You can change this verb to do whatever you want it to whenever anything is said or done in a room. 2.7. My MOO checkpoints every hour. I want to change this but I don't know where to look. Change the value of the property #0.dump_interval to the desired number of seconds between dumps; the change will take effect after the next checkpoint. This is documented in the LambdaMOO Programmer's Manual, Checkpointing the Database. 3. Miscellaneous 3.1. Where can I find the answer to... Always try the FAQ and the MOO-Cows archives, and FAQs about other subjects if they apply. Pointers to the archives and sources to get other forms of this FAQ are in the Resources section. The next question has some pointers to UNIX resources for UNIX questions. Also look at the introduction to LambdaCore document that comes with the latest LambdaCore. 3.2. I'm new to UNIX, and I need to .. You might be interested in reading one or more comp.unix.question FAQs . Reading other comp.unix.* FAQs might give you more information about your particular flavor of UNIX. Another good source of answers is rtfm.mit.edu. 3.3. I want to port something from one MOO to another. Who do I ask for permission? The owner of the object. If you can't get in touch with the owner and the object's description doesn't explicitly grant permission to port, assume you can't port the object. If the owner of the object is not a real player (e.g. hacker), then contact the administrators of the MOO. The USENET Copyright FAQ is a good source for information about copyrights. Note that an object being on a MOO and readable by everyone isn't sufficient permission to port it to another MOO. Finally, If the object isn't a generic object, ask yourself if you really want to port it or if you instead want to make an original object. 3.4. What are some good clients to use with MOO? Most people prefer to use TinyFugue or the emacs client, mud.el. mud.el is available at PARC's FTP site . Other clients are available at ftp://ftp.math.okstate.edu/pub/muds/clients VMS users might be interested in the port of tinyfugue 2.x by Mike Shiminok. It's available from ftp://ftp.math.okstate.edu/pub/muds/clients/tfvms. 3.5. How do I change my MOO password? I've forgotten or lost the password to #2! How do I log into my MOO? If you are using LambdaMOO 1.8.0 or later, run the MOO server in emergency wizard mode, eval #2.password = crypt("new-password"), and quit saving the database. Once you do this, #2's password should be set to "new-password". unix:~> moo -e yourdb.db yourdb.new MOO (#2): eval #2.password = crypt("new-password") MOO (#2): quit If you are using an older version of the server and if you are still capable of connecting as the wizard (i.e., you either haven't yet given the wizard a password or you know the current one), then the command @password (old-password) (new-password) will do it (where (old-password) is just omitted if this is the first time you're giving the wizard a password). If, on the other hand, you cannot currently connect as that wizard, but you can connect as some other wizard, then the somewhat more arcane command ;#2.password = crypt("new-password") will do it (where `new-password' is the new password). Finally, if you're completely locked out of all available wizard accounts, then you're down to the nitty-gritty task of hand-editing the database file. First, while the MOO is running, connect as some programmer and type ;crypt("foo") It will give you back a random-looking string. Write it down very precisely, making sure to match case. Then, bring the database file into your favorite text editor and search for the string ``#2'' all alone on a line. It should be followed, on the next line, by the name of the wizard (probably `Wizard' if it hasn't been changed since the MOO was started). Scroll down a ways (perhaps quite a ways, but not past the place that has `#3' all alone on a line) until you find another random-looking string the same length as the one crypt() returned above. Replace that string with the one you wrote down and save the file. You should now be able to log in as the wizard using the password `foo'. 3.6. How do I subscribe to/unsubscribe from this list? Send a message to MOO-Cows-request@parc.xerox.com with an empty subject and either subscribe or unsubscribe in the body. 3.7. How can I obtain additional copies of this list? The MOO-Cows FAQ is available via anonymous FTP from ftp://ftp.ccs.neu.edu/pub/mud/docs/faqs/ It is also available via the WWW at http://www.ccs.neu.edu/home/fox/moo/. 4. Other Resources 4.1. Information Sources of information o rec.games.mud.* FAQs < http://www.math.okstate.edu/~jds/mudfaqs.html> o New Archwizard FAQ o Lost Library of MOO o LPMOO o WinMOO FAQ o Upgrading LambdaCore to 1.8.0 4.2. Archives Archives of patches, messages, etc. o MOO-Cows list o MOO-Cows WWW archive (wariat.org) o MOO-Cows WWW archive (the-b.org) o LambdaMOO server o MOO server patches o MUD clients o More MUD clients