[MUD-Dev] WWW/INN/news systems (Was: Re: mud websites)

Petri Virkkula pvirkkul at cc.hut.fi
Tue Jun 23 09:58:04 CEST 1998


>>>>> "JCLawrence" == J C Lawrence <claw at under.engr.sgi.com> writes:

JCLawrence> Password authentication for NNTP servers is not common,
JCLawrence> but it exists and is fairly widely used.  IIRC its an
JCLawrence> optional module with INN.

	The generic password authentication is standard with INN's
	NNRP. NNRP uses a configuratio file called nnrp.access that
	has following fields:

hosts:perms:username:password:patterns

	an example line:

*:Read Post:argon:XXXXXXXXXXX:batmud.*,!batmud.guilds.*,batmud.guilds.mage

	The password is not crypt()'ed, thoigh it was straightforward
	to add support for that. As others have already written
	Netscape and GNUS/Emacs support the generic password
	authentication (I have already tested that). The nnrp.access
	file can be easily generated automatically (for example once a
	day) for example inside the mud.


	BatMUD has had its internal news system for a long time with
	over 36 newsgroups. The news system supports also external
	news readers (only GNUS is verified to work because that's what
	archwizards use), though posting privilege has been granted
	only to archwizards and to few wizards (based on IDENT
	information). Players would like to read and send news, and
	that's why I am adding better support. The internal news
	system does not support well multiple news servers.

	The system will be something like in following picture:


         Netscape/GNUS/rn/etc.
                 |
                 | NNTP protocol between user and lepakko
                 |
                 v
        +--------+---------+
        |   INN in lepakko |
        +--------+---------+
                 |
                 | NNTP protocol between lepakko and mud
		 |
		 |
	Outside	world 
	----------------------------------------------------------------
        MUD      |
		 |
                 v
        +--------+---------+
        |     mud's NNTP   |  GDBM database for message-id
        |     server       +-------------------------------
	|                  |  to article mapping
        +--------+---------+
                 |
                 | fetch_article_bynumber, store_article
		 | list_newsgroups, etc.
                 v
        +--------+---------+
        |   mud's internal | load articles from the disk based
        |       news       +----------------------------------
	|                  | on its newsgroup and number
        +--------+---------+
                 ^
                 |
                 |
                 |
         old news interface
          inside the mud


	[our two machines have names lepakko.bat.org and bat.org
	(aka. batmud.bat.org)]


	Our old NNTP server does not support message ids, that's why I
	am adding DBM-like interface to GDBM functions that can be
	used by a new NNTP server (it is generic interface supporting
	data serialization and will probably be used for other
	purposes too). No direct client access will be allowed to that
	NNTP server in the future. All future access will go through
	the external INN server.

	We are fortunate to have two machines. The newer is only
	running the mud, and the older is used as WWW and FTP
	server. Wizards have also almost full (chroot'ed) shell access
	to the older machine too (they have many editors to choose
	from, like GNU Emacs, vi and pico). As it has spare CPU cycles
	available I decided that trying to distribute news system load
	to the older machine might be a good idea.

	Atleast we are using WWW and other external servers to support
	the main thing, ie. the mud. Our WWW-server is not so fancy,
	it is only give some support info (though failing in that
	badly, one of our players has setup better WWW-pages and we
	provide link to there). Basically the idea is to remove as
	many services from the mud as possible and put them to the old
	machine. For example, our WWW server was originally written in
	LPC, but now we are using Apache in the old machine. Others
	seem to do opposite and integrating more services to a mud.


	Petri





More information about the mud-dev-archive mailing list