GlowMUCK Logo

Home Documentation MUF Docs GlowMUF Downloads Bug Tracking Support Requests Feature Requests

Main Builtin Commands Admin's Guide ANSI Color Substitution Terminology Levels

GlowMuck Administrator's Guide

Table Of Contents

  1. Setting up the Server
    1. Installing the software (unix)
      1. Getting the software
      2. Compiling GlowMuck
    2. Installing the software (windows)
    3. The bare database
    4. Deciding wizard player levels
    5. Installing MUF programs
  2. Site Blocking
  3. Web Pages
    1. Setting up the web server
    2. Creating the weg pages and links
  4. Welcome screens
  5. Wizard Commands

1. Setting up the Server

If the operating system of your server is a unix-like OS (Linux, BSD, etc.) go to section 1.1 on how to install the server. If you will be running the muck on a windows machine (e.g. Windows 95, 98, ME, NT 4.0, Windows 2000) you'll want to read section 1.2. If you're running it on windows and you are planning on recompiling the server yourself using MSVC, you may want to skim through the section on compiling as well (section 1.1.2).

1.1: Installing the software (Unix)

The best OS to run Glow or any other muck is Linux. It will compile on other forms of Unix, but some may require that you remove the -Werror entry in Makefile and/or to get the server to compile. GlowMuck should compile with the options -Wall -Werror clean. If you find that it doesn't please submit a bug report on the sourceforge site.

Things you will need:

A quick overview of the steps you'll have to go through to get Glow Setup:

1.1.1 Getting the Software

You'll want to obtain the latest version from

Step by Step:
Below, wherever you see 3.x.x or 1.x.x, fill in the correct numbers for the current release.

  1. Obtain both the glowmuck-3.x.x.tgz and the fmglowmuf-1.x.x.tgz from the sourceforge site mentioned above.
  2. Transfer the files to the account you'll be running the muck on.
  3. Log into the account's shell
  4. Type: tar -zxf glow-3.x.x.tgz (or whatever file that you downloaded) and press enter
  5. Type: mv glow-3.x.x glow
  6. Proceed to Section 1.1.2: Compiling Glowmuck

1.1.2 Compiling Glowmuck

The first step is to run a program called configure which figures out what your compiler does and does not support and configures glowmuck accordingly. To run configure:

  1. Type: cd ~/glow/src (enter)
  2. Type: configure (enter)

Configure should mutter at you for maybe a minute (how long it takes will depend on how fast or overloaded your server is) saying things like: "checking for gcc", "checking for -lsocket", etc. If everything goes well, the last thing it says should be:

    creating inc/autoconf.h
    You should review the options in inc/config.h, and
    then type 'make' to build your system.  If you plan to
    modify the source code, do 'make depend' before 'make'.
    Don't forget to copy your local.h file into the inc directory.

That last part about local.h is pretty important. There are several compile time options you can set to change the functionality of the GlowMuck Server. All of them should be set in the local.h file which is located in glow/src/inc. That way, if you want to upgrade to a new version, the only file you need to copy is the local.h file.

All the options to be set in the local.h file are set through use of C's #define pre-processor directive. To make sure a option is set to "on" you put in the file something like this:

#ifndef OPTIONA
#define OPTIONA

The #ifndef... part checks to make sure the option isn't already defined which would cause an error if you tried to define it again. #define 'defines' the option, which turns it back on. (For those of you that know C, this probably sounds overly simplified...sorry.) The last line '#endif' simply tells the compiler that you're done with this particular option block.

To turn an option "off" you'd put something like the following in the file:

#ifdef OPTIONA (check to see if the option is, in fact, turned on)
#undef OPTIONA (turn it off)
~/ #endif OPTIONA (we're done)

Some of the options take a specific parameter instead of being turned on or off. For example:

#ifdef NOBUILD_MESG (check to see if it's already been defined)
#undef NOBUILD_MESG (undefine it, since it's already defined)
#define NOBUILD_MESG "Building is currently disabled." (set the message using the new definition)

A list of possible #defines is on a separate page: GlowMuck Compile Time Options.

After you have edited local.h to your satisfaction. You'll need to start the actual compilation of the server. Start by making sure you're in the source directory (cd ~/glow/src). Then type 'make install'. It should tell you things like:

gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c boolexp.c
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c case.c
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c cast.c
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c color.c
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c compile.c
            ( more of the same )
            ( finally ... )
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c resolver.c
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -o resolver resolver.o -lm -lc
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c util/olddecomp.c
rm -f olddecompress
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -o olddecompress olddecomp.o oldcompress.o
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -c topwords.c
rm -f topwords
gcc -O2 -g -Wall -DHAVE_CONFIG_H -I../src/inc -o topwords topwords.o hashtab.o
mv -f glowmuck resolver olddecompress topwords ../game

This process may take a bit, depending on the speed and memory of the machine your compiling on. If you encounter any errors during this process, you'll need to submit a support request on the sourceforge project bug tracker with a copy of the errors you encountered and the result from a 'uname -a' command and what version of glowmuck you were compiling.

Hopefully, at this point, the server has compiled. The next step is to make a couple of changes in the ~/glow/game/restart file. There are three parameters that you may need to set. The first is the PORTS parameter, the line should look like: PORTS="9999". In place of the 9999, you need to put the port number that your provider assigned to you. The second you may not have to set. If your provider told you to use a specific IP address you will need to change the ADDR="" line to ADDR="" where should be replaced with the address your provider told you to use. The third parameter is the filename of the database file without the extension, DB="dbname". After changing those things save the file and proceed to the next step!

There is a database file provided with the minimum objects (#0 and #1) needed for the muck to startup. You'll want to make a copy of the file named the same as you specificed in the restart file (DB="dbname"). To do this you'll change into the data directory (cd ~/glow/game/data) and issue the copy command: cp minimal.db dbname.db, where dbname is the name you put in the restart file. Use cd .. to go back to the ~/glow/game directory...and type: restart & to start the server!

1.2. Installing the software (Windows)

A Windows 95 version of the server is available at the sourceforge project site: addition to the precompiled version in that zip file you will also need a copy of the full distribution from the that same site. The winglow archive does NOT contain all the files you need to get a new muck going from scratch. Make sure when uncompressing the tar file(s) that everything is uncompressed in binary mode (turn off 'smart CR/LF conversion'). Databases between Windows 95 and Unix are binary compatible and cannot be edited with programs such as 'MS-DOS edit' or Windows 95/98's note pad. Only unix editors such as 'vi', 'joe', or 'emacs' are safe to edit databases if you need to fix corruption that @sanity won't fix. DO NOT use pico! If you need a windows based editor, you can use an editor such as Programmer's File Editor or NT-Emacs that preserves CR/LFs as is and DOES NOT automatically wrap the text.

Step by Step:

  1. Download the file from the sourceforge glowmuck project site
  2. Download the glow-3.x.x.tgz file from the sourceforge glowmuck project site
  3. Open the the glow-3.x.x.tgz file in WinZip (You should be able to double-click on it if you have Winzip instaleld)
  4. Turn off Smart CR/LF Conversion (Options Menu, Configuration)
  5. Extract the archive to somewhere useful, probably easiest is the root of a drive you have about 10-30MB free
  6. Rename the glow-3.x.x directory to simply glow
  7. Extract the file into glow/game
  8. Edit the glow/game/restart.bat file, changing the following as appropiate:
  9. Make a copy of the file minimal.db in glow/game/data and name it glow.db
  10. Make the following directories in glow/game: muf, logs, and logs, make an 'oldlogs' directory in the logs directory
  11. Try running the restart.bat file. You should end up with two different 'dos' windows, one of which will say something like 'LOAD: data\glow.db', etc. If you see an error like "Out of Environment Space" on the other 'dos' window:
    1. Press ctrl-c in the 'glowmuck' dos-window and then click on the close button of the other window.
    2. Right Click on the restart.bat file, and go to Properties
    3. Click on the Memory Tab, and then change the 'Initial Environment' setting to something like 4096.
    4. Click Apply, and then OK.
    5. Run restart.bat again.
  12. You should now have the server running.
  13. One more thing you'll want to do is put a file in glow/game/data named: welcome1.txt, which will be your initial login screen.

1.3. The bare(minimal) database

We highly recommend a certain structure for new databases to make administration easier. Create one wizard set W3 to own muf programs, and another wizard set W2 to own "the world", e.g., the public rooms, exits and paths. Set both wizards GUEST. This will allow mages to have access to public rooms they would otherwise not control because these wizards are higher than them. A mage will not be able to control an object with a higher permission level than theirs. A mage/wizard can use @permission if they can't figure out why they can't control something.

After you have your wizards, create a core room or rooms to hold muf program objects and other internal items. Create a parent room or a a set of them (use @trace in a room to see what rooms are parented to it.) Don't put any global actions on #0. Often player junk ends up in #0 and it can be hard to tell the real actions from junk. Keep #0 clean and just use it for property settings that the whole muck uses such as @registered objects, site information, etc etc. Additionally, I would leave #0 owned by #1, and NEVER set #1 Guest. Furthermore, I wouldn't make #1 your primary character. Make a separate character with relatively normal 'powers'. #1 really shouldn't be for every day use, only logged into when you _have_ to use #1 to change something.

Now make a starting room for players to be created in and @tune your player_start to point to it. Usually I create 50-100 dummy objects between room 10 and 100 so if you have items you want to give low db numbers later on, you can @rec one of these and create the item. I generally start loading muf programs above dbref #100.

Another recommendation is that any global exits/programs you add should display a help screen if you type 'look exitname'. Glow supports easy additions to the 'help' command by looking at an exit if it exists and is set M1 or higher instead of trying to find internal help on the topic. This means if you have it set that way and the user types 'help exitname' they'll get that commands help. Thus you can easily expand help that users need without having to edit help.txt.

Some recommended settings on #0:

1.4. Deciding wizard player levels

The concept of wizard levels is one of the biggest pains in the arse about running a muck. It is one of those things that you give away freely and people love, but the instant you try to take it away you have made an enemy for life most times. Before giving anyone a wizbit make sure you explain to them exactly what they are to do and not do with it. Have a firm wizard policy in place. There is no danger greater than just giving away a 'free wizbit', even to friends you trust. Many head-wizards have lost and lessened many good friendships over wizbits.

We highly recommend against giving people other than yourself as headwiz a 'BOY' or W4 bit. The W4 bit is intended to allow you to have a Man character without having to log in as #1. The only thing you can't do as a Boy that the Man can do is set other people W4. All @tune settings should be available that the Man can do.

Furthermore, I'd think twice before giving a player a wizard bit at all. Consider first what duties the player will have as a staff-member. Do they really need a w-bit to do that work? Perhaps a builder's bit would do just as well or perhaps a mucker bit?

GlowMuck's wizard levels are designed so that most wizardly duties on a player relations level can be done with a W1 'Mage' bit. The only tasks that should require higher bits would be for writing programs. You might think of having a master 'muf' wizard and a master building wizard with a W3 or W2 respectively, and have them coordinate with other wizards when they have items that require a higher wizbit.

The permissions system right now is that Mages (W1) can examine anything on the muck, but can only modify items not set tinkerproof (the owner is set Tinkerproof but the item is not set Tinker). They cannot examine @/props (where site info and mail, etc is stored.) Wizards (W2) can examine @/props and do more wizardly duties like @shutdown. Wizards cannot override Tinkerproof restrictions however. Archwizards (W3) can examine @/props and control items whether they are tinkerproof or not. No wizard can modify items owned by a higher wizard unless that wizard is set Guest and the item to be modified is at or below the wizard's own level. For more information about wizard levels see the levels table.

The permissions system is subject to change as we try to iron out what each level needs to do their duties. Mages are basically player relations and builders, Wizards and Archwizards tend to be forms of headwizards and/or coding wizards that require the higher bit levels.

1.5. Installing muf programs

Loading muf programs is the biggest pain. That's why everyone wants a better starting db. The way to start is first to get /register installed. You can use either the latest Foxen version or the one that comes with glowmuf. Right now many foxen programs in the glowmuf distribution are way out of date. If you do decide to go the foxen route, I highly recommend loading the whole foxen set of libraries and commands, and then add in only the glow versions of libraries and programs that don't exist in the foxen set. One exception to this is page/mail. The program is very different despite seeming the same from the standard foxen page program. It stores mail in properties only wizards can get access to, keeping other non-wizard programmers from being able to read your mail.

The most important glow muf program to install is /path. This enables the special fake exits that save a lot of db space on the server. One large thing to note about /path is that if you create paths with it and later decide you don't want to use the program, there will be no way to convert paths back to exits (besides writing your own converter program.) I recommend /path for any muck that is starting new because it can cut your db size (and the RAM base objects use) in half or more.

Some notes on /path:

  1. Install /userprop first, then install /path. You need to register /path with /userprop to use the 'd' directory.
  2. If your muck uses a different directory you will need to @tune the path_dir setting on the muck.
  3. Also don't forget to @tune the path_prog setting to point to /path, otherwise you won't be able to use /path without a huge global n;w;s;e;etc exit.

2. Site Blocking

There are several levels of blocking you can do to prevent people from doing things you don't want. Each level includes the level before it, i.e., sites blocked from guest access can't request characters.

We keep this on #0 for reference:

@set #0=/@/s0:Use 0's for * matching, ie: for 127.*.*.*
@set #0=/@/s1:Format: @set #0=@/sites/ n:why... where 'n' is:
@set #0=/@/s2:x = BLOCKED -- cannot get to connect screen
@set #0=/@/s3:l = LOCKOUT -- cannot connect (without user flag)
@set #0=/@/s4:g = NOGUEST -- cannot connect to any guests
@set #0=/@/s5:r = REQUEST -- cannot request chars from site
@set #0=/@/s6:u = USEROK -- set on user to allow connect from site

Blocked means the connection is dropped as soon as we see the address. If they try to get on a lot a special denial of service mode goes into place to prevent status log spamming or bogging down the machine. Use the @dos command to see if someone has triggered this. You should only use IP (e.g. addresses here, if you use a DNS address ( it won't work.

Lockout means normally players can't connect. Only players that have an '@/site/ u:Let em in' setting on their player objects can connect from one of these sites. There is also a '@/login/ u' propdir that should anything be set in there, a player can only login from that site. Often useful for wizchars to keep other people from connecting as them. Right now the @jerk command has some support for site blocking, but we as yet to make a @login site to let players set what sites they can connect from to protect themselves, bit of a pain.

Noguest means no guests can connect from the site or network.

Request means that character requests and creations on the login screen or as a guest will not be accepted from the site or network.

Lastly the Userok setting only works on players to override a site or network's lockout setting.

2.1. Per site or network

The @/site, @/login, and @/welcome settings all support a simple form of wildcard matching where zeros are considered * characters and will match any address in this range. This is only valid for a given digit set if the ones to the right of it are also zero. Ie 123.456.0.123 will only match one site. If you aren't familiar with how internet numbers work I would recommend digging up some research material on it. There are several good TCP/IP books out there. It's rather important to understand network addressing in TCP/IP and what subnets are in order to be sure you have secured your muck from rogue hackers and tinyjerks.

2.2. Per email address

You can specify a slightly better wildcard matching in the @/jerks subdirectory of room #0. In there you can specify email address patterns that should not be allowed automatic online registration. This is very useful to prevent huge sites like America Online and other places that offer anonymous e-mail accounts from being able to request one or more characters with no easy way of believing the person is who they claim to be.

2.3. Per user

It is possible to lock out players completely for a while, or suspend themfor a specified time interval. The muf /jerk program is the easiest way to set these features up. They are stored in the @/lockout-msg and @/suspend-until properties of a player. Players without an @/id prop will also not be able to connect if they are not a wizard unless you turn off the mortals_need_id_prop @tune setting.

3. Web pages

3.1. Setting up the web server

GlowMuck has a built in web server capable of serving up html pages (and running MUF CGI Scripts) to a web browser. To turn these features on, you need to have #HTTPD defined (and probably #HTTPDELAY should be defined as well) when you compile the server. You also will need to set the following @tune system parameters:

@tune www_port=<portnumber>
@tune www_root=<object>
@tune www_user=<player>
@tune log_www_activity=<yes|no>
@tune www_player_pages=<yes|no>
@tune restricted_www=<

The www_port setting is the TCP/IP port that the muck's webserver will listen on. If this setting is set to zero, the webserver will be disabled. Any changes to this setting require a reboot to take effect.

The www_root setting refers to the room object that any non-player web pages will be stored on. I recommend creating a room for this purpose instead of using #0. This room will need to be set WWW_OK if restricted_www is turned on.

The www_user setting refers to the player object that when CGI MUF Scripts are run they are run as if that player ran them. If it is set to #-1 or an invalid user, muf and MPI cgi scripts won't execute. No one should log into this character normally, however logging into the character should allow simple debugging of output sent through the web connection. This user must be set Guest and have no muffer level set for security reasons. All programs must also be set L to execute via CGI. The www_user must be set WWW_OK if restricted_www is turned on.

To set up a cgi muf program, simply set the dbref number as a WWW property. The stack contains everything after a ? character in an http GET command, the command variable contains "(Web) " and then the descriptor number, host address, and text property fetched. The loc variable contains the object the property was retrieved from. To set up an MPI cgi program, start the property with a &, and then the MPI script. The program must be link_ok and will need to be WWW_OK if restricted_www is turned on.

The log_www_activity setting turns on and off logging of HTTP requests to a file. The www_player_pages setting turns on or off the ability of players to have their own web pages. If restricted_www is turned on, players or MUF programs will have to have the WWW_OK flag set for them to be able to use the web page features.

To access the website from a web browser you would use one of the following:

3.2. Creating the weg pages and links

All the web info is stored in the property _/www. If you want only a simple redirection to a web page stored somewhere else, you could @set <player|www_rootobject>=_/www: For example, to redirect my player's web to my personal page: @set me=_/www:

If you don't have a homepage anywhere else, you can write one using lsedit or create one in any text editor and use TF's /quote function to quote it into lsedit. Generally it goes something like this:
lsedit me=_/www
(Type or quote in HTML Code)
.end (saves and exits lsedit...use .help for more commands)

Lastly, to create other pages under the root page, just put the name of the page after the _/www/:

@set me=_/www/search: (make go to yahoo)

lsedit me=_/www/search (edit an actual HTML page accessible via

4. Welcome screens

The default welcome screen set include a special welcome screen that is shown for sites that are blocked for one reason or another, a nice pretty FBI logo. If you look above you will see how to make it so blocked sites will show the normal welcome screen, or else point the FBI warning screen to your normal welcome screen using symbolic links.

Welcome Screen Files (Unix)

Put one welcome screen in a file, then use symbolic links to link them as welcome1.txt, welcome2.txt, etc, in the game/data directory. These are used for the random welcome screen shower as set by the @tune rand_screens option. You can set items in the #0=@/welcome/ directory to allow custom welcome screens for certain sites, along with a banned screen for those whose sites are under suspicion and locked out for one reason or another.

Welcome Screen Files (Windows)

Create individual files in game/data named welcome1.txt, welcome2.txt, etc. These are used for the random welcome screen shower as set by a @tune rand_screens option. You can set items in the #0=@/welcome/ directory to allow custom welcome screens for certain sites, along with a banned screen for those whose sites are under suspicion and locked out for one reason or another.

legacy.txt and fbi.txt are sample files to see how to create your own login screens. You need an editor such as 'joe' for Linux which supports adding Ctrl-Ms in the text file. (You should see some bold Ms at the end of each line.) This is needed because some telnets will not do proper linefeeding if the Ctrl-Ms are not there. (Dos CR-LF vs Unix only doing LF.)

You will want to change the symbolic link game/data/welcome.txt to point to your own welcome screen:

  1. cd /glow/game/data
  2. rm -f welcome.txt
  3. ln -s welcome/yourscreen.txt welcome.txt

The way to add custom welcome screens on a per site basis, you can specify domains using the same pattern matching used for the @/sites/ site locking system. The format is slightly different to allow for proper sorting of the properties in the @/welcome directory so site-specific settings take precedence over larger domain entries. You specify a property that starts with a level, then an ip number mask. The property should start with a one word screen name followed by any comment explaining why you did it. Because of sorting, 0 priority items take precedence over priority 1 items, etc. If you wish to use 2 or more digits for priorities, pad smaller digits with 0s as the comparision used is a string based comparision, not numerical. For best results set the priority to the number of 0 '*' matches in the ip number.

5. Wizard feeps

The feeps list for wizards in Glow is so enormous it is really hard to document. We have tried to add new 'help' entries for as many things as he has found or remembered adding. So look over the command list from 'help', particularly commands starting with @. New commands are often at the bottom of the page because it is a pain trying to re-alphabetize it when adding new commands. If you find undocumented commands missing from help.txt please let us know (submit a bug report).

5.1. LogWall and descriptor commands

One of the spiffy features of Glow is the ability to monitor welcome screen activity and help out guests. Wizards doing this are usually W2 or W3 and have the LOGWALL flag set, which lets them see connections and disconnections of players. Using WHO! with the ! on the end will show the Wizard WHO list that will include anyone sitting on the welcome screen. Each connection has a descriptor number that you can use several commands to monitor or communicate with.

GlowMuck Administrator's Guide / Revised 2005 March 28 19:07 (Monday)
© 2005 Glowmuck Development Group

Valid XHTML 1.1! Valid CSS!