Campaignd

campaignd is the software used by Wesnoth.org to run the add-ons server since Wesnoth 1.0. Despite its name and the continued use of the "campaign" term both in its protocol and internal implementation details in C++, the add-ons server is capable of serving add-ons of any kind, rather than just campaigns.

This page describes various aspects of the server's functionality. The server's WML protocol is described in CampaignServerWML.

Platform support

As of Wesnoth 1.15.2, campaignd is only properly supported, tested, and used on Wesnoth.org, which runs Debian GNU/Linux. There are portions of campaignd which require POSIX functionality not found on Windows, but other than those it is expected to at least run on that platform.

In particular, the following functionality, is only available on POSIX platforms:

Executing hooks
Windows does not implement the exec* or fork system calls.
Reloading the configuration and blacklist on SIGHUP
Windows does not implement the POSIX signals concept.
Safe atomic commits of configuration and add-on pack files
Windows does not offer a mechanism to atomically overwrite files like POSIX does with the rename system call.
Sending commands to the server through a named pipe (FIFO)
Windows does not implement POSIX named pipes. It does have a native mechanism to define and use named pipes using the Win32 API — however, in pratice it is inaccessible to end users without specific tools not included with the operating system.

Command line options and signals

As of Wesnoth 1.15.2, campaignd has no command line options.

Sending SIGHUP to the campaignd process will instruct it to re-read the configuration file and blacklist file (if applicable) as soon as it finishes the current operation. Sending SIGINT or SIGTERM will result in the add-ons server process' termination. However, contrary to the message sent out to stderr in this event, it will flush its configuration before exiting, although it may be left in an inconsistent state if an add-on is currently being uploaded or deleted.

Configuration and pack files

campaignd stores information about the add-ons server's structure as WML in a config file located in the process' initial working directory, named ./server.cfg. While all metadata for the add-ons is retrieved from the server configuration WML, the add-ons themselves are stored in packs in the ./data/ directory, each pack file named after the add-on's unique name. Packs are compressed using gzip with a configurable compression level.

server.cfg

# Path to the blacklist WML file
blacklist_file=""
# Gzip compression level used for packs stored on disk
compress_level=6
# Path to a named pipe (FIFO) used for sending commands to the add-ons server
control_socket=""
# Command line executed after an add-on is successfully deleted from the server
hook_post_erase=""
# Command line executed after an add-on is successfully uploaded to the server
hook_post_upload=""
# Port number to listen for client connections. The default number depends on
# the Wesnoth version and is hardcoded in the default_campaignd_port constant in
# src/addon/validation.cpp
port=""
# Whether the add-ons server is operating in read-only mode
read_only=no
# Add-on download requests from IP addresses matching this list of glob patterns
# will not incur in a download count bump. By default this is an empty list, but
# a valid example to avoid LAN and host downloads increasing the count would be
# "192.161.*,127.0.0.1"
stats_exempt_ips=""

# The server info block. Presently, if missing, all values in this are assumed to
# be empty strings. The values below are example values reflecting Wesnoth.org's
# configuration.
[server_info]
    # The format string for add-on feedback URLs used by clients in the Add-ons
    # Manager UI. The server delivers ready-to-use URLs instead of the format
    # string. The only accepted placeholder is $topic_id, corresponding to the
    # topic_id attribute in the [feedback] tag in the .pbl file for that add-on
    feedback_url_format="https://r.wesnoth.org/t$topic_id"
[/server_info]

[campaigns]
    # Documented further below
[/campaigns]

Blacklist WML

The blacklist WML file specified in blacklist_file contains four attributes, each containing a list of glob patterns. Add-ons whose metadata matches one of these patterns may not be uploaded or updated, but they may still be deleted.

name=""
title=""
description=""
author=""
ip=""
email=""

[campaigns] tag

The [campaigns] tag contains a collection of [campaign] tags, each one describing a singular add-on using the same WML described in the [request_campaign_list] response in CampaignServerWML, plus a few sensitive or server-specific attributes:

# The add-on maintainer's email address as per PblWML
email=""
# The IP address that originated the latest upload of this add-on
upload_ip=""
# The salt and MD5 hashed passphrase for the add-on, both in Base64 format
passsalt=""
passhash=""
# Add-on's passphrase in plain text (OBSOLETE, will be converted on server startup)
passphrase=""

# The [feedback] info for the add-on as per PblWML
[feedback]
    topic_id=""
[/feedback]

Add-on packs

Add-on packs are gzipped WML with the same format and contents used for delivery to clients described in CampaignServerWML.