The first thing you have to do is to add a Customer, that is the entity that "owns" each QueueMetrics system. Click on Manage Customers from the home page:

The only mandatory field is the Company name.

After you created your customer, go back to the home page and add a system.

Enter a name that will identify this Asterisk instance, the customer and which license you want to deploy. You should also enter the address of the QueueMetrics instance (as you would use to login) and the username and password for the local keyupdater user.

The default values are:

Before doing anything with a system, it is important to check that the system is actually available on the address you entered. To do so, click on the Check button next to the URL field.

If all went well, you should receive a confirmation message.

When initially deploying a license, you can click on the Generate Now button to generate the key and have it deployed. In a few seconds the QueueMetrics system will be provisioned and active.

As in real-life you have contracts that may have any duration, it is possible to set an expiration date and have the license automatically generated every time it is about to expire. This is what the cron job does.

When the cron job runs, it basically asks two questions:

In case a license is generated but the installation fails (e.g. that particular QM instance is down), then the cron job will repeatedly try to install that key, until it succeeds. A detailed activity trace is held on the system log.

Please note that the new license will be renewed until it covers at least the expiry date - not a big issue if your licenses are paid on a weekly basis, but if they are e.g. monthly and the license is renewed the second day of the month, it will however last until the end of that month.

As soon as your business grows, your PPK list will get very large and searching for relationships between PPKs, keys generated and associated instances could be difficult. To help you to identify which PPK was used by a specific QM instance, which key is deployed to a QueueMetrics instance, its validity perriod and its activation date, a set of filtering options was implemented.

Switching to the Manage Licences page the whole list of PPKs is shown, independently by the status each PPK has. For each Generated and/or Activated PPKs the Start Validity and End Validity columns are populated with their relevant information. Generated and/or Activated keys have an icon in the More info column. Click on this icon to have detailed information about a specific PPK; a popup box opens as shown in the picture below.

Through the two dropdown lists present on the right side of the page is possible to filter the PPK list by licence type and/or licence status. To have the filtered list you should select which licence type and/or status you need to list, then click on the Filter button.

Each time a user edits/inserts a customer or a QM Instance, each time the batch processor runs or a user manually triggers a key generation/activation process, a set of activity events are generated and logged on the keyring database.

These events could be inspected for security reasons or to better understand what happened if something went wrong by clicking on the of the View Syslog page. The View Syslog link is available only to users holding the key SYSLOG. In order to assign a specific key to the user please refer to User Accounts and Security

In order to extend and/or reduce an existing license, you create a new one and replace the old one with it. It is immediately active. The old one is basically "dumped" and cannot be recycled.

In case you should run out of the PPK required for that client, it will be impossible to generate the key and an error message will be logged. (We plan to add email notifications in the near future).

If a QueueMetrics license key expires, the whole application might become unavailable. This does not usually happen the very day the key expires, but after its expiry date a QM instance may stop working at any moment. When this happens, even the remote key deployment webservice becomes unavailable, and so the Keyring cannot restart that QM instance.

If this happens to you:

Access to the LowayKeyring pages is granted by mean of a pairs of username and password tokens. These should be present in the list of authorized users. Each user is related to a specific class. Classes are a set of containers where security keys are grouped. Each security key is a token that, when hold by a user or a class, allows the holding user to do a specific action or set of actions.

In order to add, edit, delete users, an administrator should click on the Manage Users link on the top of the page. Only adminstrators, or better, only users holding the USRADMIN key are allowed to enter to the user’s administration page. From this page is possible to define, edit or delete a set of classes. Each class should have a unique name and a set of security keys that will be applied to each user inheriting that class. From this page is also possible to define, edit or delete a set of users. Each user should have a unique name, a password, and should inherit from a specific class. It’s also possible to assign a specific security key to one or more users.

A security key is usually made by a case insensitive text-based token. Some security keys are pre-defined by the LowayKeyring framework. This means that they could be used to activate specific actions for users holding that key. An example is the USRADMIN that enables user definitions page for the user holding that key.