Campaignd - Revision history

Pentarctagon: /* Configuration and pack files */

2021-03-17T04:36:08Z

‎Configuration and pack files

Pentarctagon: /* server.cfg */

2021-03-17T04:33:49Z

‎server.cfg

Shadowm: /* Process signals */ Correction from loonycyborg

2019-11-24T19:08:48Z

‎Process signals: Correction from loonycyborg

Shadowm at 02:33, 24 November 2019

2019-11-24T02:33:05Z

Shadowm at 01:10, 24 November 2019

2019-11-24T01:10:02Z

Shadowm: /* Process signals */ big oops

2019-11-24T01:04:27Z

‎Process signals: big oops

Shadowm: /* Process signals */

2019-11-24T01:02:48Z

‎Process signals

Shadowm: /* Platform support */

2019-11-24T00:59:17Z

‎Platform support

Shadowm: /* See Also */

2019-11-24T00:57:52Z

‎See Also

Shadowm at 00:56, 24 November 2019

2019-11-24T00:56:56Z

← Older revision		Revision as of 04:36, 17 March 2021
Line 29:		Line 29:

	campaignd stores information about the add-ons server's structure as WML in a config file located in the process' initial working directory, named <code>./server.cfg</code>. While all metadata for the add-ons is retrieved from the server configuration WML, the add-ons themselves are stored in packs in the <code>./data/</code> directory, each pack file named after the add-on's unique name. Packs are compressed using gzip with a configurable compression level.		campaignd stores information about the add-ons server's structure as WML in a config file located in the process' initial working directory, named <code>./server.cfg</code>. While all metadata for the add-ons is retrieved from the server configuration WML, the add-ons themselves are stored in packs in the <code>./data/</code> directory, each pack file named after the add-on's unique name. Packs are compressed using gzip with a configurable compression level.
		+
		+	As of 1.15.10, campaignd also has database support via mariadbpp to store add-on information and validate topic IDs of uploaded add-ons.

	=== server.cfg ===		=== server.cfg ===

@@ Line 68: / Line 68: @@
      # 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]

@@ Line 24: / Line 24: @@
 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 <b>will</b> flush its configuration before exiting, although it may be left in an inconsistent state if an add-on is currently being uploaded or deleted; furthermore, if the platform does not support atomic commits, an add-on's pack file may be left in an inconsistent state as well.
+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 <b>will</b> finish the current operation and flush its configuration before exiting.
 == Configuration and pack files ==

@@ Line 14: / Line 14: @@
 * <b>Reloading the configuration and blacklist on SIGHUP</b><br>Windows does not implement the POSIX signals concept.
 * <b>Safe atomic commits of configuration and add-on pack files</b><br>Windows does not offer a mechanism to atomically overwrite files like POSIX does with the <code>rename</code> system call.
-* <b>Sending commands to the server through a named pipe (FIFO)</b><br>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 practice it is inaccessible to end users without special tools not included with the operating system.
+* <b>Sending commands to the server through a named pipe (FIFO)</b><br>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 practice it is inaccessible to end users without special tools not included with the operating system. See also [https://github.com/wesnoth/wesnoth/issues/4594 issue #4594].
 == Command line options ==
@@ Line 157: / Line 157: @@
 <b>Syntax:</b> <code>setattr <var>ADDON_ID</var> <var>ATTRIBUTE_KEY</var> <var>ATTRIBUTE_VALUE</var></code>
-Overwrites the specified WML attribute for the add-on in its <code>[campaigns][campaign]</code> metadata block (but not in the add-on's pack file). This is only practical for single-line values since it's not possible to send a multi-line string (such as the add-on's description) as part of a single socket command at this time.
+Overwrites the specified WML attribute for the add-on in its <code>[campaigns][campaign]</code> metadata block, but not in the add-on's pack file ([https://github.com/wesnoth/wesnoth/issues/4595 issue #4595]). This is only practical for single-line values since it's not possible to send a multi-line string (such as the add-on's description) as part of a single socket command at this time.
 Authentication attributes (<code>passphrase=</code>, <code>passhash=</code>, <code>passsalt=</code>) cannot be modified using this mechanism. Use <code>setpass</code> for those instead. Likewise, it is not possible to use this to rename an add-on (<code>name=</code>) or set attributes that are not already recorded in its metadata block.

← Older revision		Revision as of 01:10, 24 November 2019
Line 1:		Line 1:
		+	<div class="tright"> __TOC__ </div>
		+
	[[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.		[[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.

@@ Line 22: / Line 22: @@
 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 <b>will</b> flush its configuration before exiting, although it may be left in an inconsistent state if an add-on is currently being uploaded or deleted.
+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 <b>will</b> flush its configuration before exiting, although it may be left in an inconsistent state if an add-on is currently being uploaded or deleted and the platform does not support atomic commits.
 == Configuration and pack files ==

@@ Line 7: / Line 7: @@
 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:
+In particular, the following functionality is only available on POSIX platforms:
-* Executing hooks<br>Windows does not implement the <code>exec*</code> or <code>fork</code> system calls.
+* <b>Executing hooks</b><br>Windows does not implement the <code>exec*</code> or <code>fork</code> system calls.
-* Reloading the configuration and blacklist on SIGHUP<br>Windows does not implement the POSIX signals concept.
+* <b>Reloading the configuration and blacklist on SIGHUP</b><br>Windows does not implement the POSIX signals concept.
-* Safe atomic commits of configuration and add-on pack files<br>Windows does not offer a mechanism to atomically overwrite files like POSIX does with the <code>rename</code> system call.
+* <b>Safe atomic commits of configuration and add-on pack files</b><br>Windows does not offer a mechanism to atomically overwrite files like POSIX does with the <code>rename</code> system call.
-* Sending commands to the server through a named pipe (FIFO)<br>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.
+* <b>Sending commands to the server through a named pipe (FIFO)</b><br>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 practice it is inaccessible to end users without special tools not included with the operating system.
 == Command line options ==

@@ Line 179: / Line 179: @@
 == See Also ==
-* CampaignServerWML
+* [[CampaignServerWML]]
-* PblWML
+* [[PblWML]]
 [[Category:Server Documentation]]

← Older revision		Revision as of 00:56, 24 November 2019
Line 176:		Line 176:

	In the present day, this functionality is wholly untested and unsupported.		In the present day, this functionality is wholly untested and unsupported.
		+
		+	== See Also ==
		+
		+	* CampaignServerWML
		+	* PblWML

	[[Category:Server Documentation]]		[[Category:Server Documentation]]