If you are a MUD admin and want to make it easy for your players to access the MUD over the web,
or if you want to host your own instance of Worldwideportal to access other MUDs, this guide is
for you.
No matter which option you take, you'll need either a Linux system of some form. This could be the same system you host your MUD on, or a different one if necessary. You could self-host, or use a cheap cloud instance (try Linode, Vultr, DigitalOcean etc..., or find a provider on Lowendbox). Mac or Windows users can either manually run a Linux VM (and be sure to forward the ports mentioned to it), or use Docker Desktop or similar container technology that automatically runs containers in a VM.
Worldwideportal provides a few options for how you set it up, ranging from really quick and easy
options where everything is automated, to options that give you more control. Pick the option that
seems best for you.
Don't worry if you don't understand everything here - just default to the simplest option if you don't understand the details, and follow the steps.
* Simplest: Let Worldwideportal handle everything, including managing certificates, and expose its ports directly to the Internet. Run it in a container for one-line deployment. This requires that port 80 (the web port) and your main HTTPS port (443 recommended since it is the default) are not used for anything else - for example, that you are not also running a web server on the same system.
* Or: Provide Worldwideportal with a certificate you request externally. Notify it when the certificate is updated. Run it in a container for one-line deployment. Let Worldwideportal listen on the HTTPS port you want inbound connections from.
* Or: Run Worldwideportal from a container without enabling TLS (HTTPS), but set it up so it is only accesible locally. Then reverse proxy to it, and provide TLS offload (i.e. HTTPS) from a web server already running on your server.
* Or: Build Worldwideportal from source for complete flexibility and control, including the ability to apply your own custom patches to it.
Make sure you allow forwarding to the relevant ports through the firewall (if you have one turned on). This will vary by distribution. If using ufw, try: `sudo ufw default allow routed`
(adjust the 443 to whatever port you are listening on if you want to require a port number).
Try connecting to Worldwideportal at `https://your-mud-hostname.org/` (adjusting the hostname; if you aren't using port 443, put the port in the URL like `https://your-mud-hostname.org:port/`). You will expect an error about a non-trusted certificate (since you used LetsEncrypt staging for now) - but not an error that you can't connect.
If you do experience other problems (e.g. because LetsEncrypt staging can't connect to your server using your hostname to verify the certificate, or you got the configuration wrong), you can diagnose the problem by checking the logs. When using podman, use `sudo journalctl -xe -t worldwideportal` to view the logs, which should tell you what is going wrong.
To switch to a certificate recognised by browsers, edit `/etc/worldwideportal/worldwideportal.toml` and uncomment (remove the `#` from the start of the line) the line `acme_provider = "https://acme-v02.api.letsencrypt.org/directory"`. Similarly, comment out (add a `#` to the start) the line mentioning acme-staging-v02. Then delete the old certificate / key / account file: `sudo rm /etc/worldwideportal/privkey.pem /etc/worldwideportal/fullchain.pem /etc/worldwideportal/acme_account.json`, and restart worldwideportal with `podman restart worldwideportal`.
Connect to it again to check that everything works.
Follow option 1, except delete the entire section of `/etc/worldwideportal/worldwideportal.toml` starting at `[tls.acme]`.
Before starting the server, copy your PEM-formatted X.509 certificate (including the full chain of certificates) - colloquially called an SSL certificate - into `/etc/worldwideportal/fullchain.pem`. Copy the corresponding private key into `/etc/worldwideportal/privkey.pem`.
Whenever you rotate the certificate (e.g. from Certbot or similar), copy the new files over these files, and tell worldwideportal to reload its configuration with `kill -HUP $(pidof worldwideportal-server)` from your certificate renewal hook (or manually). This won't disconnect users who are connected.
Follow the instructions in option 1, but leave delete the `[tls]` and `[tls.acme]` sections. You probably want to change the default port from 443 to avoid confusion, since in this case `worldwideportal` will speak plain HTTP.
When you start your container, you'll probably want to give it a static local IP. Run `sudo podman network inspect podman` to find the subnet range for the default network (often `10.88.0.0/16`, meaning anything under `10.88`). Pick an unused address in the subnet, e.g. `10.88.143.12` if the subnet is `10.88.0.0/16`, and add `--ip 10.88.143.12` to the podman command when starting the container for the first time.
When you configure your server to proxy to Worldwideportal, note that there are two types of requests:
* Requests to GET static assets for Worldwideportal over normal HTTP.
* WebSocket requests to `/ws`.
Many reverse proxies need special configuration for WebSockets. e.g. for Apache Httpd mod_proxy, `ProxyPass "/ws" ws://10.88.143.12:1234/ws`. For nginx, you'll need something like:
Follow the instructions from [https://doc.rust-lang.org/cargo/getting-started/installation.html](https://doc.rust-lang.org/cargo/getting-started/installation.html).
The quickest option there is to run `curl https://sh.rustup.rs -sSf | sh`.
