Comet Server configuration 

Overview 

Comet Server can be configured either via the Setup Wizard, or by editing the configuration file directly.

This guide will include screenshots of the Setup Wizard where appropriate, and also include references to the configuration file.

Setup Wizard 

You can configure Comet Server via the Setup Wizard.

You can access the Setup Wizard by logging in to the Comet Server web interface, clicking "About this server", then clicking "Setup Wizard" button.

(Prior to Comet 17.6.0, it was also possible to access the Setup Wizard by clicking the "Setup Wizard" menu item in Comet Server Service Manager on Windows.)

Configuration file 

As an alternative to the Setup Wizard, it is possible to edit the Comet Server's configuration via the cometd.cfg file. You can edit this file if you are experiencing any issues accessing the Comet Server web interface.

File validation and access 

The configuration file is in JSON format. Any changes made to this file must be valid JSON syntax. This mostly boils down to escaping backslash characters in text strings - wherever you intend for a backslash (\) character to appear, please use two backslashes (\\) instead.

The Comet Server application may overwrite any changes to the cometd.cfg file, unless it is stopped first. After making changes, you should then restart the server software following the instructions in the previous "Install the server application" section.

On Windows, if the application has been installed in the Program Files directory, then it may be necessary to run the editor as Administrator in order to save changes to the file. On Linux, the file may be owned by the root or cometd users, and it may be necessary to run the editor as a different user in order to save changes to the file.

Windows 

On Windows, Comet Server Service Manager includes a built-in configuration file editor that

  • automatically checks for valid JSON syntax, and
  • ensures that all Administrator user operations are handled correctly.

We would recommend using the Comet Server Service Manager feature to edit the cometd.cfg file on Windows.

Serial number 

Enter your serial number.

In cometd.cfg, this field can be set in the License section > SerialNumber property.

Server branding 

You can configure the appearance of the Comet Server web interface.

The top-left section of the Comet Server can be configured to display either a Comet brand logo, custom text, or a custom image.

In cometd.cfg,

  • the Branding section contains properties which can be used to modify the appearance of the Comet Server's built-in web interface.
  • the BrandName property sets the text displayed in the top-left corner.
  • if the LogoImage property is set to the path to an image on the local filesystem, this logo image will be displayed replacing the logo text
  • the CSSTheme property sets the theme used for the web interface. This property has the following possible values:
    • The value $default$, which instructs the Comet Server to load the default theme.
    • Any path to a *.css file on the local filesystem.

Email 

Comet Server can be configured to send email reports. To use this functionality, you should configure how email is sent.

You should set the "Send as" properties to configure how email appears to the recipient.

In cometd.cfg, these properties can be set in the Email section > FromEmail and FromName properties.

Delivery method 

You can choose to send email via one of four options:

None (Do not send email) 

Select this option to disable sending email from the Comet Server.

The Comet Server will be unable to send email. You can use this option if you want to disable all outbound email from a Comet Server.

In cometd.cfg, this option can be set in the Email section > set the Mode property to "" (empty string).

MX Direct 

MX Direct allows you to send email from this Comet Server without needing to configure a custom SMTP server. However, there is a greater chance of the email being discarded as spam.

In cometd.cfg, this option can be set in the Email section > set the Mode property to "builtin".

SMTP Server 

If this option is enabled, Comet will send email via an SMTP server.

The following options should be configured:

  • SMTP server address
  • SMTP server port
  • Username
  • Password
  • Accept invalid SSL certificate from the remote SMTP server
  • Connect using TLS, instead of plain+STARTTLS
  • Allow sending emails over an insecure connection

Gmail account 

If this option is enabled, Comet will send email via a Gmail account. Internally, this uses known configuration information for Gmail's SMTP server.

The following options should be configured:

  • Email address
  • Password

Network 

Configure which network interfaces and URLs the Comet Server will be accessible on.

The Comet Server can listen on multiple addresses, ports, and interfaces.

Change host/port, or use multiple ports 

By default, the Comet Server listens for connections on 127.0.0.1 port 8060. It is expected that this would be changed to e.g. port 80 or 443. Once the hostname and port are configured for the first time, they should be kept the same so that any installed client software will still be able to log in.

In cometd.cfg, each listener is configured with an object under the ListenAddresses section. Each object entry in the ListenAddresses section has (at minimum) a ListenAddress property, which should be a text string in the format ip:port.

Comet Server supports binding to an IPv6 address. You may need to enter IPv6 bind addresses using square-bracket syntax (e.g. [0000:1111::2222]).

Configure SSL Certificate 

Configuring an SSL certificate is very strongly recommended to improve security, as malicious network operators are no longer able to intercept passwords.

Using an SSL certificate with Comet Server also increases performance. The server will only negotiate an HTTP/2 pipelined connection if an SSL certificate is configured. This significantly improves TCP utilization.

In addition to this, some web browsers will show a warning

  • if the login page is not protected by SSL (e.g. Chrome 56, released January 2017), or
  • if the website is not protected by SSL (e.g. Chrome 68, to be released in July 2018).

Use an existing SSL certificate 

In one object within the ListenAddresses section, make the following changes:

  • Change the ListenAddress property to use the port 443.
  • Set the new SSLCertPath property, to be a path to a local certificate file. The certificate should be in X.509 (PEM) format, including any intermediate certificates.
  • Set the new SSLCertKey property, to be a path to a local certificate key file. The key file should be in X.509 (PEM) format and should not be encrypted.

Use a free, automatically-renewing SSL certificate 

Comet Server integrates Let's Encrypt support, allowing you to receive a free valid SSL certificate for the Comet Server. The certificate is trusted by all major web browsers, it will be renewed automatically, and requires no intervention from the server administrator. The only requirements for this feature are

  • The server must be listening on port 443; and
  • the domain name must be publicly accessible, and the DNS for the domain name must point to this specific Comet Server instance.

In order to enable this feature, make the following changes to your object entry under the ListenAddresses key;

  • Set the ListenAddress property to :443
  • Set the new AutoSSLDomains property to a comma-separated list of domain names for which the SSL certificate should be valid.

The SSL certificate provider has rate limits on certificate issuances.

  • To avoid reissuing the same certificate every time the Comet Server is restarted, Comet will automatically cache the generated SSL certificate. You can overwrite the cache paths by setting the additional properties SSLCertPath, SSLCertKey, AutoSSLRegistrationFile, and AutoSSLRegistrationKeyFile to all be local file paths.
  • If you modify your SSL configuration very frequently, you may encounter a rate limit from the SSL certificate provider, preventing the SSL certificates from being generated.
  • Current rate limits can be seen on https://letsencrypt.org/docs/rate-limits/ .
Troubleshooting 

The Comet server must be able to access letsencrypt.org in order to issue the SSL certificate.

Broken IPv6

We are aware of one server with broken IPv6 connectivity, that experienced repeated timeouts connecting to addresses under letsencrypt.org until IPv6 was disabled.

Provider downtime

You can check the status of the Let's Encrypt service at https://letsencrypt.status.io/ .

IP rate limiting 

Comet Server 17.12.9 and later support IP-based rate limiting. This reduces the bandwidth for the entire Comet Server.

To use this feature, follow these example changes to the cometd.cfg file:

"IPRateLimit": {
    "Rules": [
        {
            "MatchRegex": ".*",
            "BytesPerSecond": 1048576
        }
    ]
},

You can configure multiple rules. Each rule creates a rate-limiting domain. Incoming requests are matched against a domain, and the domain is limited as a whole. Incoming requests will be assigned to the first rate-limiting domain that matches.

Rate limits apply separately to ingress and egress traffic (e.g. a 10 MB/s limit will allow simultaneous 10 MB/s upload and 10 MB/s download).

Admin accounts 

No further documentation is available for this topic.

In cometd.cfg, each object entry in the AdminUsers section represents a user who can log in to the Comet Server interface.

Username 

There are no character nor length restrictions on administrator usernames.

Usernames are case-sensitive.

Password 

There are no character nor length restrictions on administrator passwords.

Change or reset administrator password 

You can reset the administrator password by clicking the 'Reset' button.

In cometd.cfg,

  1. Find the object entry for the user in question under the AdminUsers section.
  2. Change the PasswordFormat value to 0 (zero).
  3. Change the Password field to the desired password.
  4. The password will be hashed and encrypted after first login.

Allow login via 

Comet Server supports two-factor authentication for administrators. For more information, please see the "Configure two-factor authentication" section in the "Comet Server usage" document.

You can configure which sets of information are sufficient in order to log in to the Comet Server:

  • Password alone: if this option is checked, the password alone is sufficient to log in to the Comet Server.
  • Password and 2FA together: if this option is checked, the combination of password + TOTP code will allow the administrator to log in to the Comet Server.
  • 2FA alone: if this option is checked, the TOTP code alone is sufficient to log in to the Comet Server.

In cometd.cfg,

  • the AllowTOTPLogin property sets whether a valid TOTP code alone is sufficient to log in.
  • the AllowPasswordLogin property sets whether a valid password alone is sufficient to log in.
  • the AllowPasswordTOTPLogin property sets whether both the Password and TOTP together are sufficient to log in.

IP Whitelist 

It is possible to restrict the IP address of an Administrator logging in to Comet Server.

No further documentation is available for this topic.

Policies (Administrator account) 

It is possible to restrict the actions of administrator accounts in Comet Server.

As of Comet 17.8.0, the following restrictions are available:

  • Prevent viewing and editing server settings
  • Prevent shutting down and restarting server

Authentication Role 

The Comet server software is split into separate roles, as described in the "Application Architecture" section. If this server is expected to only play a storage role or an authentication role in your infrastructure, the other roles should be disabled.

In cometd.cfg, the AuthenticationRole > RoleEnabled option configures whether the Authentication Role is enabled.

The Authentication Role is the part of Comet Server responsible for managing users and job history logs. When this role is enabled, the following data files are used:

  • cometd-users.db - This file contains user profile information for all users. The expected filesize is small.
  • cometd-jobs.db - This file contains textual job information for all job history. The filesize may grow to some tens of MB, or larger, depending on the retention and volume of job entries.

It is not safe to copy these .db files while Comet Server is running.

Configuring Storage Role servers for Storage Vault registration (Optional) 

No further documentation is available for this topic.

Replication (Authentication Role) 

No further documentation is available for this topic.

Authentication Role Properties 

No further documentation is available for this topic.

Missed Backups 

The Authentication Role is responsible for maintaining historical logs of each job. Comet Server can generate a virtual "missed" job corresponding to when a backup job was expected to run on schedule but no backup job was found. You can control generation of Missed Backup jobs via the AuthenticationRole > GenerateMissedBackupEvents property. This property defaults to true, but has no effect if the Authentication Role is disabled.

In general, we would suggest leaving this property enabled for primary servers, and disabling it for replica servers.

Missed backups are detected the following basis:

  • A background task performs calculations every half-hour.
  • If a scheduled backup job was expected to run at time T, and no backup job for the same username, Protected Item, and Storage Vault occurred within the time range T - 5m ... T + 15m, then a missed backup job will be injected with the start and stop time set to T.

Storage Role 

The Storage Role is the part of Comet Server responsible for receiving and replicating any data uploaded by a Comet Backup account. When this role is enabled, the following data files are used:

  • cometd-buckets.db - This file contains metadata and authentication information for all Storage Vaults. The expected filesize is small.

It is not safe to copy these .db files while Comet Server is running.

In cometd.cfg, the StorageRole > RoleEnabled option configures whether the Storage Role is enabled.

Locations 

You must configure a location where this Comet Server can store data. The path might be a local disk path, or a network account, or a cloud storage provider. For more information about the supported storage types, please see the "Storage Configuration" document.

Replication (Storage Role) 

No further documentation is available for this topic.

Software Build Role 

The Software Branding Role is the part of Comet Server responsible for generating branded client software installers and making them available for download. When this role is enabled, the "Download client software" page appears in the Comet Server web interface.

Branding 

No further documentation is available for this topic.

Client new account registration 

Comet supports new account registration from within the client software. You can enable this feature by setting the AccountRegisterURL property in cometd.cfg. If this property is non-empty, then any generated software will contain a 'Register' button on the login screen that opens the property as a URL in the system default web browser.

This allows you to create a custom signup workflow that calls into the Comet Server API to actually create the account. This offers an MSP the chance to capture other information such as email address, contact details, and billing / payment details.

By deferring to an external URL for new account registration, this system is deliberately flexible. For instance, it would be possible for MSPs using this system to

  • offer the choice of multiple plans, or
  • create the account on a specific Comet Server, or
  • automatically request a first storage vault, or
  • create a "free trial" system.

Codesigning 

Recent versions of Windows and macOS have introduced measures to encourage distributing code-signed installers.

Codesigning for Windows (Authenticode) 

You can enable Authenticode signing of generated installers. Signing the installer may reduce "SmartScreen" / "unknown publisher" prompts when installing the software.

Authenticode signing requires obtaining a certificate from a commercial certificate provider. At the time of writing, the following providers offered Authenticode certificates compatible with current versions of Windows:

Once you have purchased a certificate, you can enable it in your Comet Server by setting the following properties in the cometd.cfg file:

  • WindowsCodeSignPKCS12FilePath - a path to the PKCS12 (*.pfx, *.p12 etc) file on the local disk.
  • WindowsCodeSignPKCS12Password - the password to decrypt the PKCS12 file
  • WindowsCodeSignPKCS12PasswordFormat - set to 0 when first entering a password in the WindowsCodeSignPKCS12Password field; Comet will then encrypt the password, and use this field to indicate the encryption format.

When you do NOT have a codesigning certificate enabled, the Windows software download is in the form of a zip file, containing a small loader .exe (Authenticode-signed by a partner company of Comet Software Ltd) and a data file. When you DO have a codesigning certificate enabled, the Windows software download is in the form of a zip file containing a single signed .exe.

Codesigning for macOS 

Comet Server is not able to automatically sign a macOS installer. However, you can download the .pkg file and sign it yourself, and host it for downloading on your own website.

  1. Purchase a developer ID certificate from Apple
  2. Sign the installer: productsign --sign '3rd Party Mac Developer Installer: My Company Limited' 'original-installer.pkg' 'signed-installer.pkg
  3. Check the signature: pkgutil --check-signature 'signed-installer.pkg'

A future version of Comet Server may be able to directly perform codesigning for macOS.

Software updates 

When a software update is applied, Comet tries to silently install an updated .pkg file from the Comet Server. This file will be unsigned. Comet 17.12.8 and later pass the -allowUntrusted flag to Installer.app to allow installing a software update from an unsigned .pkg file.

Codesigning for Android 

No further documentation is available for this topic.

Codesigning for Linux 

No further documentation is available for this topic.

Options 

No further documentation is available for this topic.

Constellation Role 

The Constellation Role is the part of Comet Server responsible for providing global insight across multiple Comet Servers.

Recall that Comet is designed to separate the Authentication and Storage roles to allow independent scaling.

  • A small MSP using Comet software might have only a single Comet Server,
  • A large MSP might have one Authentication Role server and a dozen Storage Role servers,
  • A white-label MSP might have a dozen different Authentication Role servers all backed by a single Storage Role server.

These latter cases are perfectly valid scenarios, but present some complexity when answering questions like "which user accounts are using this bucket" and "is this bucket safe to delete". The Constellation role communicates with all your Comet Servers to produce a global overview of your entire cluster to help answer these questions.

The Constellation role is optional. However, it is necessary if you want to automatically remove unused storage buckets from your Storage Role servers.

The Constellation role was formerly known as the "Overseer" role.

Choose one (and only one) of your servers to have the Constellation role. You can then use the Report features inside Comet Server > Cluster menu > "About this Cluster" to find which buckets are in-use by which accounts.

In cometd.cfg, you can enable the Constellation Role by setting the property ConstellationRole > RoleEnabled to true.

Targets 

No further documentation is available for this topic.

In cometd.cfg, fill the Servers array with all your servers (including the Constellation), in the same format as for replication targets and remote storage buckets.

Properties 

The Constellation role will automatically produce a bucket usage report every hour, listing for each bucket (A) which servers the bucket exists on, and (B) which users have a Storage Vault configured pointing to this bucket. This information is sufficient to identify unused buckets in order to reclaim storage space on your Comet Server.

In the default configuration, no data will be deleted as a result of running this report. Once you are happy with the result of this report, you can enable the deletion feature to allow the Constellation role to delete unused buckets automatically.

Please keep an eye on the server logs in order to draw attention to any correctness issues with the report.

In cometd.cfg, you can configure this option via the ConstellationRole section > DeleteUnusedData property.

Risks 

It is essential that the Constellation has access to every single one of your Comet servers. If a new Authentication Role server is added to your infrastructure, but not added to the list of servers managed by the Constellation Role, then Constellation will see that the buckets are unused and remove them.

Such an issue should be obvious when the customer's next backup job fails to run. If the issue is noticed early, then recovery should be possible by reverting to an earlier filesystem snapshot (if available) or by re-uploading the data. However, if backup jobs are performed infrequently, or if the issue occurs at the same time as another outage, it may be more difficult to recover from the issue.

If an Authentication Role server is found to reference a Storage Role server outside the Constellation's vision, then a warning message will be added to the log file.

Saving changes 

If you are applying changes via the Comet Server web interface, the Comet Server will restart to save your changes. The Comet Server will be automatically restarted by the service system. Any running backup jobs will resume automatically.