Home Documentation MUF Docs GlowMUF Downloads Bug Tracking Support Requests Feature Requests
Main Builtin Commands Admin's Guide ANSI Color Substitution Terminology LevelsIf 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).
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 Makefile.in 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:
You'll want to obtain the latest version from http://sourceforge.net/projects/glowmuck/
Step by Step:
Below, wherever you see 3.x.x or 1.x.x, fill in the correct numbers for the current release.
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:
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:
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:
Some of the options take a specific parameter instead of being turned on or off. For example:
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="192.168.0.1" where 192.168.0.1 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!
A Windows 95 version of the server is available at the sourceforge project site: http://sourceforge.net/projects/glowmuck/In 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:
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:
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.
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:
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: 127.0.0.0 for 127.*.*.*
@set #0=/@/s1:Format: @set #0=@/sites/1.2.3.4 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. 10.0.0.0) addresses here, if you use a DNS address (george.atsite.com) it won't work.
Lockout means normally players can't connect. Only players that have an '@/site/1.2.3.4 u:Let em in' setting on their player objects can connect from one of these sites. There is also a '@/login/1.2.3.4 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.
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.
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.
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.
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:
http://your.domain.com:www_port/
http://your.domain.com:www_port/~player
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:http://some.other.site/. For example, to redirect my player's web to my personal page: @set me=_/www:http://www.kemenel.org/feaelin/index.php.
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:http://www.yahoo.com (make http://your.domain.com:www_port/~player/search go to yahoo)
lsedit me=_/www/search (edit an actual HTML page accessible via http://your.domain.com:www_port/~player/search)
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.
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.
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:
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.
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).
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
