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.

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.

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".

Troubleshooting for failed email delivery:

Make sure the reverse DNS has been configured for your domain to help ensure the email delivery is successful. The forward DNS should match the reverse DNS.

If you do not have the access necessary to configure reverse DNS then you will need to find out who owns your IP block (usually this is your ISP or hosting provider) and contact them to configure it.

Also, you may need to configure your domain's SPF record to allow the Comet server to send emails on behalf of this domain. An SPF record is added to your domain's DNS zone file as a TXT record and it identifies authorized SMTP servers for your domain.

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.

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, released in July 2018).

Comet takes SSL certificates in X.509 (PEM) format. These files usually have a *.crt, *.cer, *.pem, or *.key file extension. They do NOT have a *.der, *.pks, *.jks, *.pfx, *.p12, *.p7b, or *.p7c extension; if your SSL certificate is in another file format, it should be converted to X.509 format.

The X.509 format is a plain-text format. You can inspect the files with a plain-text editor, like Notepad or Nano. The certificate file should start with the text -----BEGIN CERTIFICATE-----. The key file should start with the text -----BEGIN PRIVATE KEY-----.

If you have an intermediate certificate, you should combine your certificate with the intermediate certificates. You can open the files with a plain-text editor like Notepad or Nano, and paste your certificate, followed by the intermediate certificates, to build a combined file. You should use this instead of the certificate file above.

The Nginx web server requires the same process. You may find more information online about configuring intermediate certificates for Nginx.

On Linux, you can easily combine files with a command like (cat original.crt; echo; cat intermediate.crt) > combined.crt. In this example, placing echo between each cat command ensures that each file starts on a new line in the combined file.

Comet Server will probably work without the intermediate certificate, however, some web browsers may experience issues. We recommend using the third-party website https://www.ssllabs.com/ssltest/ to validate your SSL configuration for any hidden issues.

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

(since January 2018) the server must be able to listen to port 80 if necessary; 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, in the configuration file, make the following changes to your object entry under the ListenAddresses key;

Set the ListenAddress property to :443

You may specify a specific IP address (ip:443) if necessary. If your server is behind NAT, you should specify the LAN address.

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

When Let's Encrypt is used, the Comet Server associates your domain name with the valid SSL certificate.

However, if someone tries to connect to the server using https:// {direct IP} or https:// {wrong domain name} there is a problem as Comet does not have a valid certificate for the request. In the past, Comet would serve the certificate, but the client would see a mismatched-certificate error and fail. As of Comet 17.3.12, Comet Server will instead just drop the connection since there is an obvious misconfiguration.

If you see this error message including a wrong domain name:

There is a misconfiguration. Either a client is unintentionally connecting using the wrong domain name, or, you have misconfigured Let's Encrypt to not mention a domain name that should be included.

A researcher may be scanning the entire IPv4 internet using the Reverse DNS (RDNS) name of your server. It's possible that the RDNS name is out of date compared to the expected domain name for accessing this server.

If you see this error message including an IP address:

It's possible that someone tried to connect to your server on https:// {direct IP}. At the time of writing, it is not possible to receive a Let's Encrypt certificate for a bare IPv4 address.

A researcher may be scanning the entire IPv4 internet, and connecting to the open :443 port using the IP address of your server.

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.

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

This feature is not currently configurable in the web-based Setup Wizard owing to the high likelihood of locking yourself out. You must make this change in the server's configuration file: that ensures you have a way to remove it, if necessary.

In the configuration file cometd.cfg,

Find the object entry for the user in question under the AdminUsers section.

Add a IPWhitelist field, with the value, a regular expression to match against IP addresses.

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 file-size is small.

cometd-jobs.db - This file contains textual job information for all job history. The file-size may grow to some tens of MB, or larger, depending on the retention and volume of job entries.

Authentication Role Replication replicates this server's authentication role data (i.e. user profiles and policy group configurations) to the other Comet server in one direction (the replica doesn't replicate data back to the main).

You can have your Replication server store the data using a cloud service provider or using your own storage.

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.

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 documentation.

Storage Role Replication replicates this server's storage role data (i.e. storage buckets & its content) to the other Comet server in one direction (the replica doesn't replicate data back to the main).

You can have your Replication server store the data using a cloud service provider or using your own storage.

The Software Build 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.

The Comet Client Branding is for how you want to brand your company with the Comet client (click here for Server branding). When you set the branding, the next time you update the users Comet client it will automatically change (If you need to update branding for multiple devices then use the Bulk Update feature).

The Product name is what the Comet client will be named (the shortcut will automatically change to this name).

The Comet client will refer to the Company name when making changes within the Comet client.

Setting the Help URL will add a "Help" tab on the client with your URL of choice (not required).

The Default server URL will prefill the Server field when logging into the Comet client.

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

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.

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.

Linux applications do not contain embedded codesigning. You can achieve codesigning support for Linux by GPG-signing the hash of the binary and making this information available on your website independently.

A future version of Comet Server may add built-in support for package signing when hosting an apt-compatible repository for .deb packages.

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.

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.

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.

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.