MOO with LambdaMOO
ToastStunt is the actively maintained fork of LambdaMOO, updated for modern OpenSSL, 64-bit architectures, and contemporary C compilers. This guide covers compiling from source, initializing the object database, hardening security through proper wizard permissions, and configuring persistent service management. Unlike containerized MUDs, MOOs require direct compilation against system libraries and careful handling of the object database file for checkpoint consistency.
Compile ToastStunt from source with dependency resolution
Clone the ToastStunt repository and compile against modern OpenSSL. The configure script detects system capabilities, but you must explicitly enable SSL support and ensure yacc/bison are present for the parser generator. Compilation produces the 'moo' executable binary.
git clone https://github.com/ToastStunt/ToastStunt.git
cd ToastStunt
./configure --with-openssl
make -j$(nproc)⚠ Common Pitfalls
- •Compiling with incompatible OpenSSL versions (1.0 vs 3.0) causing connection failures
- •Missing yacc/bison tools producing cryptic parser errors during build
Initialize the minimal database and configure listening ports
ToastStunt requires a database file to start. Use the provided Minimal.db as a template, which contains the core object hierarchy including $root_class and $player. Bind to a high port (7777+) to avoid permission issues, or use setcap for privileged ports below 1024.
cp Minimal.db world.db
./moo world.db 7777⚠ Common Pitfalls
- •Binding to ports below 1024 requires setcap CAP_NET_BIND_SERVICE or root privileges
- •Database file permissions preventing write access during checkpointing causing corruption
Create the wizard player account and secure initial access
On first connection, the server automatically creates player #2 as the wizard with unlimited permissions. Immediately set a secure password using the in-game command to prevent unauthorized access. Do not create additional wizards until security policies are established.
@password oldpassword newpassword⚠ Common Pitfalls
- •Leaving the wizard player unpassworded exposes full server control to anyone connecting first
- •Connecting via unencrypted Telnet transmits passwords in plaintext over the network
Configure systemd service for automatic startup and crash recovery
MOO servers must run persistently and restart on crash. Create a systemd service file specifying the non-root user, WorkingDirectory (essential for relative database paths), and Restart directives. Never run the MOO as root due to built-in eval() capabilities.
[Unit]
Description=ToastStunt MOO Server
After=network.target
[Service]
Type=simple
User=moo
WorkingDirectory=/opt/moo
ExecStart=/opt/moo/toaststunt /opt/moo/world.db 7777
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target⚠ Common Pitfalls
- •Running the server as root creates security vulnerabilities through MOO's built-in system() functions
- •Missing WorkingDirectory directive causes relative path resolution failures for DB and log files
Establish core object hierarchy and parent classes
Define the fundamental object taxonomy: $thing (movable objects), $room (container spaces), $exit (connections between rooms), and $player (user avatars). Set up parent relationships correctly to inherit movement verbs and description handling. The .location property must be set for all physical objects.
@create $thing named Generic Thing
@create $room named Limbo
@parent Limbo is $room
@verb Limbo:enter this none this
@program Limbo:enter
player:tell("You enter the void.");
.⚠ Common Pitfalls
- •Circular parent references crash the server during object initialization
- •Forgetting to set .location property prevents object movement verbs from functioning
Implement verb security with correct permission bits
MOO security relies on verb permissions (rwx) and ownership. Set verbs to player_perms for user commands, wizard_perms for administrative functions. Use this.none.this for verbs that should only be callable by the object itself, preventing external invocation.
@verb #5:eval this none this
@chmod #5:eval +x
@chmod #5:eval -r⚠ Common Pitfalls
- •Leaving verbs as +x (executable) by non-owners creates privilege escalation paths
- •Incorrectly setting wizard permissions on player verbs bypasses security checks
Configure automated checkpointing and backup rotation
ToastStunt writes checkpoints to disk periodically. Implement external shell scripts triggered by cron to copy the database file during low-activity periods. Rotate backups to prevent disk exhaustion, keeping 7 days of history minimum for corruption recovery.
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
cp /opt/moo/world.db /backups/world_$DATE.db
find /backups -name "world_*.db" -mtime +7 -delete⚠ Common Pitfalls
- •Checkpointing during high-load operations causes noticeable server lag
- •Unrotated database dumps filling disk space and causing crashes when the filesystem fills
Enable SSL/TLS wrapping for secure client connections
Modern ToastStunt supports built-in SSL if compiled with --with-openssl, or use stunnel for external termination. Configure certificate chains properly; self-signed certificates work but require clients to disable verification or add the CA.
⚠ Common Pitfalls
- •Self-signed certificates rejected by modern Telnet clients without override flags
- •Incorrect certificate chain configuration preventing SSL handshake completion on connection
What you built
With the server compiled, service-managed, and secured through proper verb permissions, you can begin MOO programming by creating rooms and objects inheriting from the core hierarchy. Test checkpoint integrity by reviewing backup files, then implement custom verbs using the MOO programming language. For production deployments, consider placing the server behind a proxy for additional DDoS protection and SSL termination management.
.