MOSS/FAQ

http://assets.openuru.org/wiki/icons/note-edit-48x48.png

This page contains draft content
The content of this page is a "work-in-progress" and is subject to change. Do not place undue reliance on the completeness or accuracy of the material presented here!

Should you have any questions concerning MOSS, don't feel alone! Others have struggled where you have struggled. Here are the most frequently asked questions about MOSS and deploying a Shard running it.

General

General questions about MOSS and related subjects.

What is MOSS?

Full details can be found on MOSS' article.

To summarize, MOSS is an open-source Uru server created by a'moaca' and cjkelly1 through reverse-engineering of Cyan's server's inner workings by the analysis of network packets sent by the client (no disassembly was used). A server interfaces with a client to deliver data, files, and so on. When combined with a physical server (a computer), a software server becomes a machine on the Internet capable of remotely serving up a website, a repository of files or a game, to name a few uses. In this case, when MOSS is combined with a computer, it produces a "Shard", to which the CWE client can connect. If you wish to operate a Shard, you will have to set up a server and distribute a client that explorers can use to connect to it.

A server? Does that mean Cyan has finally open-sourced their server code?

Unfortunately, no. Cyan is apparently nowhere near a release of their code. In its stead, MOSS fills the role of a server replacement for running Uru Shards. It is a full-featured server, capable of doing practically everything Cyan's server can, so until the latter is released, all your Uru needs should be filled by MOSS, barring [few minor bugs], not all necessarily MOSS' fault.

UNIX? *nix?

Most people today are familiar with at least two operating systems (the software that powers your computer): Windows and Mac. However, there are a variety of other OSes out there, including all the UNIX-based operating systems (also called *nix OSes). To run MOSS, you need to install a *nix OS on your server. Instructions for installation depend upon which specific system you choose; if you aren't familiar with these operating systems, you might be better off by choosing one tailored for less advanced users, such as Ubuntu Server.

However, please note that for installation, a minimum of technical knowledge is required to execute instructions and input commands; it is recommended you become familiar with your server's operating system before proceeding with the setup of MOSS.

Installation

Setup-related questions. For the main installation instructions, read MOSS/Setup.

Where is MOSS installed?

The exact location where MOSS is installed by default will probably depend upon your operating system of choice (see above). For example, in the case of GNU/Linux, it will probably be installed under /usr/local, meaning you will have to start MOSS from that directory. However, if you prefer installing MOSS in a specific location, the --prefix configuration option is the answer to your problem. You might choose, for example, to install it in your home directory (~/moss, for instance), allowing the user which will run MOSS to have complete control over all the files involved.

Why would I want to "enable-fast-download"?

To fix a bug known as the "zero seconds remaining" bug, Cyan placed a type of cap on the amount of data sent over the Internet. MOSS doesn't have this bug, though, so you are free to remove this cap, therefore allowing your client to benefit from enhanced download speeds, theoretically (although actual performance will still most likely depend not on your client's download speed, but on the upload speed of your server).

Why are there three servers? I thought MOSS was already a server!

Since Cyan's client needs to communicate with four different subsystems to connect to the server, MOSS has to provide four processes which will handle all the appropriate communications; since they in turn serve specific parts of data, they are called servers too. Each has a different role:

• Auth Server: this server handles the authentication of users, checking them against the PostgreSQL database to make sure they have entered a correct combination of username and password. It also handles which SDL and Python files will be provided to the client, depending on their "class" ("default" for most cases).
• File Server: the file server keeps a list of all the files the client needs to download, with various manifests files (see below) which list them. It contains one sub-directory called Client, in turn containing External, in which all the files which the client will have to download must be provided. WARNING: you are currently NOT allowed to add Cyan content to this folder due to licensing restrictions; clients must already have downloaded the appropriate files from the official Cyan servers.
• Game Server: the game server handles every operation directly pertaining to the game, including the current state of instances and the files associated with each Age.
• Gatekeeper Server: lastly, the gatekeeper server tells the client where to find other servers.

There is a fifth, optional server called the Status Server, which will handle the display of an HTTP status message that the client will fetch and display. It is optional since you can do the same thing with any regular web page on an HTTP server.

What the heck is a "manifest", and why should I care?

A manifest is a special binary file which provides the server with a list of all the files it currently has. There are two types of manifests: authentication manifests (with the .mbam file extension), telling the auth server what files it has to offer the client, and file manifests (with the .mbm file extension), telling the file server what files it must distribute to the client and where they are located.

You'd better care about all these .mbam and .mbm files, because if you don't have manifests, your client won't know what do since the server will be scrambling around frantically, literally mumbling to itself about non-existent manifests while trying to find all the files the client is requesting to work.

You create manifests either using support/make-mbam.pl (only for auth manifests) or support/ManifestCreator.exe (the latter requires an up-to-date client installation and Windows to operate).

What do I do with all these keys?

Open locks of course! What else?

There are two types of keys:

• Private keys: these keys should be protected in such a fashion that no outside entity can read them; it's recommended to chmod 400 them to the user which will run MOSS. These need to be in the auth dir.
• Public keys: unlike private keys, there is no risk of compromising your server (at least, no elevated risk) by distributing your public keys; your client actually needs them to access your server! These can be anywhere on your server, since MOSS doesn't look at them. I recommend putting them in one directory together for convenience.

Depending on your client's implementation of keys, you will have to follow different instructions when distributing your clients to allow them to connect to your server (see below).

What's all this about global_sdl_manager?

The following section needs confirmation by someone with technical knowledge on the subject.

So you've created your database. That's fine. But wouldn't you like to configure a few things? global_sdl_manager allows you to configure all the various SDL files on your server by adding a few parameters to your database. The default settings are those of MO:ULa, without the sparklies enabled (see below).

What needs to be "secured"?

All the files in the Python and SDL folders in your auth dir need to be secured for the external clients. To accomplish this task, use the plPythonPack.exe executable in your client build to pack all the appropriate Python files into one python.pak file to be placed under auth dir/Python, then run plFileSecure.exe on all the files in auth dir/SDL and on auth dir/Python/python.pak.

Running

"The ending has not yet been written." You still have to start up your server. What follows are answers to questions that might arise while running MOSS.

Why no sparklies?

I haven't tested the following technique yet, but it seems logical to me.

This is because of the default configuration imposed by global_sdl_manager. To change this, create a file, copy the support/set_to_moul.txt file contents and uncomment (remove the # in front of the line) all lines similar to m ercaCalendarSpark07 1.

Clients

For the most part, MOSS doesn't care which client is connecting to it. However, they do differ in the way they must connect to your Shard and the scripts they must use.

Using: OpenUru.org CWE client

This client, maintained by the OpenUru.org team and built using Visual Studio 2003 (a costly product), requires being built along with your keys; in this case, you'll have to copy the three .cpp files you obtained when creating your server's keys over into your client's sources under CWE/MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/NucleusLib/pnNetBase.

Scripts distributed with the Internal client or served for the External client must be acquired here: OpenUru.org Foundry - MOULSCRIPT-ou

Using: H'uru CWE client

The H'uru team has gone another way, instead making use of a server.ini file in your client's root directory that is read not at compile-time but during run-time. Therefore you should use the CreateINI tool by MercAngel to convert your .cpp files to an appropriately formatted and unencrypted server.ini. Then just drop this file into your client's root directory.

Another difference (as described below under Troubleshooting) is the mechanism for requesting manifests.

Scripts distributed with the Internal client or served for the External client must be acquired here: GitHub - H'uru/moul-scripts

Notice: if distributing an External client, you need to encrypt your server.ini file using plFileEncrypt.exe.

What's the difference with the Internal clients?

Whereas an External client should be the one distributed to users on your server, an Internal client's purpose is to allow for debugging of problems in your Shard or in your client. It gives access to a few special features, including a fly-mode and a Python console for on-the-fly modification of the world around you and the state of age files. Unlike and External client, they are capable of working solely with local data, thus allowing you to make sure your Shard works by testing only a part of the server at a time (since it doesn't interface with the file server, for example). In addition to the dat and sfx folders, they should be provided with a copy of your moul-scripts as used on your server (when running in LocalData mode).

What do I put in file dir/Client/External?

Every file that goes in this directory will be downloaded by your client when it connects to your Shard and detects out-of-date files. This includes UruLauncher.exe and UruExplorer.exe. The exact set of files will depend on the fork of the CWE client you are using. For reference, take a look at the files used by the Gehn Shard (H'uru CWE client) and by the Minkata Shard (OpenUru.org CWE client).

The files in this directory all need to be gzipped. When you use ManifestCreator to create your file manifests, so long as you point it to a working external client installation instead of the regular Uru Live folder, it automatically gzips all the client files in your installation directory (excluding game data).

Licensing

Remember that you're using open-source software; as such, proper credits must be given where due. Details are available on MOSS/Setup

How should I distribute the license for my client?

The best way to be sure your clients always have your license available is to include it under your install dir/Client/External as a gzipped filed to be automatically downloaded when a client connects to your Shard.

What needs to made available publicly?

Aside from the license distributed to your clients, you need to provide a link (on your Shard's website for example) to the source you used both for your client and for your scripts. If you are using unmodified sources, you need to link to the exact revision you cloned for your client.

Troubleshooting

If you encounter any problems while running MOSS, this section will address some of the most frequent issues.

"Server tried to mumble to itself about SecurePreloader.mbm, but no one is listening."

This warning from MOSS means that someone is using the H'uru CWE client to connect to your server. It's safe to ignore it. It simply means that the H'uru team has implemented an alternate mechanism for requesting the manifests and that MOSS doesn't understand it, and tells so. The client doesn't mind, and then falls back on the default method of relying on the auth manifests, as described above.

See Also

• MOSS
• MOSS/Notes
• MOSS/Setup
• MOSS/Distribution Specific Instructions
• MOSS/Developer Notes
• MOSS/FAQ