To upgrade Comet Server on Windows, run the updated installer file. The old version will be uninstalled and replaced with the new version. Your configuration will be preserved. Any running backup jobs should resume automatically.

For Comet Server 17.3.11 and older, the .deb package supports Debian 8 "Jessie" or compatible. The package expects the presence of systemd as the init system and depends on the locales-all package not present in Ubuntu 14.04 or older.

When upgrading from a distribution using SysVinit or Upstart (e.g. Debian 6, Debian 7, Ubuntu 12.04, Ubuntu 14.04) to a distribution using systemd (e.g. Debian 8, Ubuntu 16.04), the Comet Server unit is not enabled in systemd and will not start automatically. You can resolve this issue by

To upgrade Comet Server on Debian-based distributions, install the updated .deb file. The old version will be uninstalled and replaced with the new version. Your configuration will be preserved. Any running backup jobs should resume automatically.

Future versions of Comet will provide integrated packages for Synology and QNAP NAS devices. In the meantime, if your NAS has an x86_64 CPU and you have SSH access to your NAS device, you can install Comet Server using the "Other distribution" package.

Future versions of Comet Server will provide installation packages for a variety of popular server distributions.

If you are using a Linux distribution without an available package, your support agent will be unable to assist with any issues related to your specific operating system. Different Linux distributions use different service managers, init systems, user management scripts, and filesystem hierarchies; the following instructions are deliberately vague as a result.

The server software can be installed as follows:

Create a new restricted user to run the application.

Extract the provided archive.

Set permissions on the extracted files to match the created user, and mark the cometd binary as executable.

Switch to the restricted user, and run the application once with the argument -ValidateConfigOnly. This will cause a default configuration file to be generated.

Write a service management script (e.g. systemd unit file) to manage the service.

Proceed to enter a serial number in the configuration file, as described in following sections.

On Linux, binding to ports below 1024 (e.g. the common 80 or 443) requires authorization from the root user. There are many ways to achieve this: for example, you can run setcap CAP_NET_BIND_SERVICE=+eip /path/to/cometd as root (requires kernel 2.6.24 or newer), or investigate the authbind package for more granular control.

The server can be started at any time, by either

opening a terminal as the restricted user, and typing ./cometd ; or

by starting the service using the service management script (e.g. systemd unit).

The latter should be preferred in general, but the former may be more convenient during initial configuration and for diagnostic purposes.

Comet Server for Linux requires the IANA timezone database to be available unpacked in the /usr/share/zoneinfo/ directory. This package is likely already installed by your distribution vendor.

The Comet Server binary (i.e. cometd.exe on Windows / cometd on Linux) accepts a number of command-line arguments to configure its behavior.

-ValidateConfigOnly

This flag causes Comet Server to validate the cometd.cfg file, creating it if it does not already exist, and then exit immediately.

-LogAccesses

This flag causes Comet Server to add log entries for all HTTP accesses. This option can cause a lot of information to be generated and should be used sparingly when troubleshooting network issues.

-Chdir=C:/custom-path/

This flag causes Comet Server to look in a different directory for its read-write files, such as cometd.cfg and database files.

-Instdir=C:/custom-path/

This flag causes Comet Server to look in a different directory for its read-only files, such as /vendor/.

-WebrootDir=C:/custom-path/

This flag causes Comet Server to not use the built-in web interface, and instead use a custom web interface from the supplied directory. This option could be used to enable advanced customization of the web interface, or to disable the web interface entirely.

The built-in web interface is entirely API-driven; modifying or disabling the web interface in this way has no impact upon any other uses of the product (including backup or restore operations).