Daliserver Dave Weininger Daylight CIS

• Starting with Release 4.71, Daylight will be providing a license management service called "Dali", which has the ability to manage Daylight licenses for all computers on a given network.

• Dali can dramatically reduce administrative overhead associated with licensing, both for the customer and the vendor (Daylight).

• Dali is backwards compatible with the earlier Daylight licensing methods

• Dali is "given" a number of license files to manage

• Dali can authenticate license requests from users/programs

• All dali management is done via the network interface

• Dali logs all actions

• Dali is accountable

• All dali requests are handled via HTTP, just like any other webserver.

• Specific authentications appear as paths, e.g., a request to authenticate a Thor server license for a particular machine:

  http://dmz:5581/dali/lic/cpu/690d8f73/program/merlin

• Authentications are done using the HTTP HEAD protocol and are validated using encrypted header contents. Results are communcated via the normal "200 OK" or "404 Not Found" HTTP return values.

• When a path is requested with the HTTP GET protocol (as with a browser request), an HTML message is generated as shown here.

• HTML is generated for informational and administrative requests, e.g., http://dmz:5581/

• Interactivity is implemented using HTTP POST (FORMs) as in this example. Multipart encoding is supported for uploading license files.

Aside from programatic license authentication, Dali provides a very limited number of services to normal users.

• Find the Daylight license for my computer.

• Show basic daliserver status.

• Help.

• Dali supports one level of privileged users, known as Dali managers.

• Dali managers can reconfigure the server, add and remove licenses, authorize or revoke authorization of other managers, etc. The only things they can't do is delete log/password files and shut down the server.

• Managers are authorized by name and password, which must be done (or revoked) by a password-authenticated manager.

• A one-hour, non-persistent authentication cookie is used to make administration more convenient.

• Management task are access via a "menu" page.

• Daliserver appears to be a full featured HTTP server which supports HEAD, GET, POST CGIs, URL and multi-part encodings, GIF/JPG files, etc. It is. However, it is not implmented in the normal manner with a large number of .html files, CGI scripts, executable binaries, etc.

• Aside from any license files which might be loaded, the whole daliserver subsystem consists of one program (daliserver) and just two files (password and log files).

• Everything else -- HTML, FORMs, even JPG images -- are invented "on the fly". This makes the system very simple, robust, easy to install, and easy to maintain.

• Hint: this may be the form of a future DayCGI server.

The Daylight 4.71 license manager has been modified to take advantage of Dali services. The license policy allows three license information sources which are specified by environment variables:

• DY_DALI_SERVICE / DY_DALI_SERVICE_TOMS

  This is the first to be checked and is intended to be a dali service on the local area network, e.g., "hostname:dali". The timeout is typically set short, default is 500 (TOMS = timeout in milliseconds, so 500 = 1/2 second).

• DY_LICENSEDATA

  If DY_DALI_SERVICE is undefined or the request fails, the DY_LICENSEDATA file is checked. This functions identically to pre-4.71 behavior.

• DY_DALI_AUTHORITY / DY_DALI_AUTHORITY_TOMS

  This specifies an additional network license server to be checked if the first two information sources fail. The intention is to make this a fallover which is accessed via proxy, e.g., "www.daylight.com:dali" and to set the timeout fairly long (default is 5000 or 5 sec.)

• Run without license services

  Same-old-same-old: don't define network services, don't run daliserver, put a license file on each machine and define DY_LICENSEDATA.

• Run with license services on your LAN

  Operate a local license service, name it in DY_DALI_SERVICE, and centralize license management.

• Run license services with local file backup

  Do both of the above. If dali service fails for some reason, the software will fall back to local license file. Recommended for servers (at least initially).

• Run local license services with network backup

  Run daliservers on two machines on your LAN, name one as the primary service and the other as the authority service. This provides local fallover redundancy in case of hardware (but not network) failure. This strategy might be sensible for global licensees.

• Run license services with remote backup

  Operate a daliserver on your LAN, define both local and authority services. If the authority service is set to "www.daylight.com:dali", your Daylight software will always run even if your local service fails for some reason. Recommended for all installations with HTTP proxies.

• Run exclusively with remote license services

  Define the authority service as "www.daylight.com:dali" and do nothing else. All license requests will be handled by Daylight authority. Not recommended for general use, provides great benefits for demonstration purposes.

• Centralized license management

  No longer need to install license files on each computer. Should be an improvement for corporate licensees.

• Failsafe operation

  Despite best efforts all around, not all license files get updated on all machines. Dali provides a solution in most such cases.

• Automatic demonstration/beta licensing

  Demo and beta software can be shipped with the authority service set to daliserver at www.daylight.com. On systems with HTTP proxies, this software should run out "of the box" (out of the tar) without the inconvenient licensing step.

• Simplified license updating

  Daliserver can handle multiple licenses for a given CPU; authorization is given if it occurs in any license. We no longer have to replace licenses in toto, which should be convenient all around.

• Network licensing

  Pervasive computing is becoming a reality. As time goes on, it's becoming less sensible to license software on a per-CPU basis and more sensible to do so on a per-network basis. Dali will allow us to move to network licenses, e.g.,

  http://lama:5581/dali/lic/net/207.17.60.*/program/fingerprint

• Automated license updating

  The initial implementation of Dali allows clients to get license information from daliserver(s) in a network transaction. It's a short step to allow daliservers to access each other, i.e., periodically (or on any authorization failure?) check an authority source for an updated licenses. This might eliminate the requirement for customers to deal with license files at all.