Reprise Software’s Recommended Software Installation Steps
[Note: This information is in the RLM Reference manual, in the "End-User Installation" chapter, but we felt it was important enough to repeat here.]
Installing your product with RLM should be very straightforward, and should require no configuration of environment variables, etc.
Overview:
On the client side, ie, on the machines where your application is going to run, place the license file in your product hierarchy. For nodelocked licenses, this should be the actual, signed license file, and nothing needs to be done to this license file. For floating, this license file will be used only to locate the license server host.
If you ship floating licenses, install the server binaries and license file on the server node. The server license file doesn't need to be modified.
Nothing in this set of recommendations requires the use of environment variables, and the install-time editing of license files is kept to a minimum (No editing of license files for nodelocked licenses, and only the server hostname needs to be set on the client side for floating licenses).
Details:
During development:
- establish a directory in your installed product tree for license file(s). This could be the same directory where your product is installed.
- Pass the directory from the step above as the first argument to rlm_init().
When you ship a nodelocked license:
- If you are shipping uncounted or single node-locked licenses, put the actual licenses into the license file. Install in the default directory. You're done.
When you ship a floating license:
- If you are shipping floating licenses, use a single HOST line in the license file for the client side. Use the default RLM port (5053) - which means you do not need a port number in this license file, and fill in the hostname with the name of the server computer at installation time. This license file should look like this:
HOST server-hostname
- On the server node, place the rlm binary, your ISVsettings file (or ISV server binary), and the license file in a directory. This license file should have the real, signed licenses. The server hostname in this file can be “localhost”, meaning that it doesn't have to be edited by the end-user. The server license file's first two lines should look like this:
-
- HOST localhost hostid
ISV your-isvname - use the default port (5053)
- use the ISV server settings or binary from the same directory as the rlm binary
By configuring the license file this way, it does not need to be edited by your customer. These lines tell RLM to:
Of course, you would include all your signed LICENSE lines in this file as well.
- Start the rlm server from the directory in the step above
If your customer already has another RLM server running:
- Install your ISV settings or server binary and the license file in the same directory as the other product's copy of the server binaries and license files, and do a “reread” operation on the running rlm. That's it, however:
- If your version of RLM is newer than the installed version, update the installed version to your version, then shut down the running rlm and start the new one.
If you ship new, additional licenses to your customer:
- Put the new license file in the same directory as the old one. If they are nodelocked licenses, put them on the client system. If they are floating licenses, put them into the directory with your other licenses and do an rlmreread on the license server.
When do I need the RLM License Server?
The Reprise License Manager product is capable of supporting many license types. Some are appropriate for standalone, single-user licensing models and others are used to support more complex network licensing and pricing scenarios. Determining when a license server must be installed is not always clear.
So, let's spend a few minutes talking about the various jobs a license server performs, and when it is needed to support various license types.
Uncounted v. Counted Licenses
The biggest factor that determines whether a license server is required is whether licenses are counted or uncounted. Counted licenses require a license server because it must "count" concurrent licenses. Counted licenses are used whenever the ISV wants to limit or record concurrent license usage. Counted licenses can be identified by a positive integer in the "count" field of the license.
Uncounted licenses, on the other hand, do not require a license server because there is no need to count usage. Uncounted licenses can be identified by the word "uncounted" or or the number "0" in the license count field of the license. Each uncounted license must be node-locked to a hostid. For ease of administration at larger sites, uncounted licenses for multiple computers may reside in a license file that is managed by a central license server, but this is not required.
The other license type that does not require a license server is the "single" license type. This is also a node-locked license, but it can be used by only one user at a time (concurrent count of "1"). The enforcement of "single" licenses is done via file locking, not by license servers.
The RLM License Server
The basic job of the RLM License Server is to service license requests from RLM-enabled client applications over the network. Based on the needs of the application, the license server redirects license requests to the ISV-specific license server which actually grants or denies the request based on what is specified in the license and on the current usage conditions.
License servers also manage "roaming," named-user, and token-based licenses. They manage held and shared licenses, and offer an admin interface, diagnostic tools, and are responsible for writing debug and report logs.
Licensing Mobile Users with RLM
Roaming Licenses with RLM
If you sell floating licenses for your software products, you can increase the value of your licenses by allowing them to be removed from the network when your users hit the road.
With RLM, you can give users a license that will allow them to remain in compliance even after they've disconnected their laptop from the corporate network. Whether for a few hours, a few days or a few weeks, "roaming" licenses can be valuable to your users, and set you apart from your competition.
Increasingly, users want to take their work “on the road.” RLM’s built-in license roaming capability allows users to check out a license from a server, physically disconnect from the server and continue to use the license for a specified number of days, after which the license is automatically returned to the server when it expires on the mobile computer.
As an ISV, you control whether licenses are allowed to roam, and how long they can be checked-out in the disconnected state. No API changes are required beyond providing a special rlm_roam license to your customer.
RLM license roaming was designed to allow ‘disconnected’ use for short durations up to a few weeks.
Using Dongles with RLM
Supporting dongles with the Reprise License Manager
The Reprise License Manager (RLM) comes with built-in USB dongle support. That means that dongles purchased from Reprise can be used as a standard "hostid" to which licenses can be locked. The principal advantage of using dongles is to provide a convenient way for your customers to transfer licenses when machines are replaced or upgraded. Software applications, with a valid license, can be used on any machine as long as the dongle specified in the license is attached.
ISV-Defined Hostids
ISVs who prefer to support their own dongles with RLM can do so by way of an ISV-defined host ID. ISVs can choose a simple, low-cost dongle because RLM needs only the dongle's serial number at runtime. ISVs then write a routine to retrieve the dongle's ID and include that routine within the RLM libraries so whenever a license is tied to the dongle, RLM knows how to call the ISV's routine to obtain the dongle serial number. Example code is provided with the standard RLM SDK to show how ISV-defined hostids can be integrated into RLM.
Managing Renewable Licenses – A Practical Approach
Using RLM refresh-type activation to support short-term renewable licenses
Consider these licensing system requirements:
- The system must be able to generate a time limited and trial licenses.
- The trial version will automatically become a "full version" when the customer purchases a license.
- Full licenses are also "time limited", i.e. customers can purchase packages of 30, 60, or 90 days.
- Each time the application starts, it must validate that its license has not yet expired.
- The application must be able to operate "off line" for a specified period of time: if the license cannot be reactivated at the expiration of the allowed off-line period, then the license is suspended and the application cannot start.
- Upon first reconnection, if the user still has a valid license (has not been terminated), the license is reactivated, the off-line allowed time is restored and the application can be run again.
Supporting the Concepts
Using the optional RLM add-on product, RLM Activation Pro, a refreshable license is one that is intended to be reactivated frequently and receive a license with a new expiration date with each reactivation. Refreshable licenses are typically of short duration (days). The ISV is assured that the maximum period during which the end user can run the licensed application is the duration of the refreshable license, say 30 days.
For example, if the ISV specifies a 30-day refreshable license, then the license will be good for 30-days after each activation. If the refresh operation fails for any reason, such as the lack of Internet connectivity, then the license is still good until the end of the 30 day period - enough time to resolve any connectivity issues. This allows the customer to operate off-line until the license needs to be refreshed.
Refreshable licenses also give the ISV a way to revoke a license should that user fail to meet contractual obligations, for example. The ISV can simply disable the user's license on the activation server, and refresh attempts of that license will fail from that point forward, or until it is re-enabled by the ISV.
The client side of refreshing can be automated, so it can be performed without an undue burden on the end-user. Reprise supplies a "Refresh API" for license refreshing, which the ISV can use from within the application itself, or within a separate standalone utility. Reprise supplies a generic refresh utility that can be supplied to the end-user by the ISV. The generic utility, "refresh_util", is meant to be set up to run daily as a scheduled task.
ISV-Defined Hostids
Defining new Hostids within RLM
RLM comes with a comprehensive set of integrated hostids, but there are times when ISVs need to lock their software licenses to something else. The three most common reasons for ISV-defined hostids are:
- Supporting non-Reprise dongles
- Tying licenses to peripheral hardware devices
- Combining various identifying elements of the computer.
ISV-Defined Hostid
RLM provides the ability to extend the native set of hostids by using your own routines to obtain host identification which is unique to you.
In order to do this, you use the rlm_add_isv_hostid() call in your application. If you want to support multiple instances of your hostid type on a single computer, you would use the rlm_add_isv_hostid_multiple() call.
For more information on ISV-defined hostids, please consult the latest RLM Reference Manual or contact Reprise Software.
RLM End User Bundle
RLM End User Bundle for License Administrators and End Users
The RLM End User Bundle is designed to give end users and license administrators everything they need to maximize their use of RLM-licensed applications, the bundle contains the most-current RLM license server, and a tool, "rlmtests," to help with license server and network capacity planning.
The RLM End User Bundle includes some testing tools that let License Administrators answer questions such as:
- How fast can my license server service license requests?
- How many licensed users can my server handle?
- What will my performance be if I double my current user population?
- When should I split my license inventory into multiple independent license servers?
‘rlmtests’ is totally self-contained, creating the required test licenses and then starting a license server before it runs the tests, finally reporting the results on the screen. The rlmtests utility performs two categories of tests: checkout performance tests and server capacity tests.
With this utility, license administrators and other end users can be proactive about their hardware requirements, matching available hardware to expected needs and developing a plan for hardware acquisition to match the growth in users of RLM-licensed software.
The RLM End User Bundle can be downloaded from the RLM end user support page: http://www.reprisesoftware.com/support/end-users.php
How to Produce RLM Report Logs
SUMMARY: RLM license servers can produce detailed report logs of the license activity of your products. By default, these log files are turned off. This article will explain the potential uses of these report log files, what they are and how to tell your RLM license server to start producing them.
User Benefits
Users of products that use RLM license servers for floating or concurrent licenses use report logs for:
- Proof of internal license compliance
- Allocating costs across departments who share licenses.
- Asset and maintenance cost optimization and budget planning
- Entering into and monitor usage-based software licensing agreements
ISV Benefits
Software vendors benefit from report logs too. They can be used to:
- Reconcile over-usage
- Build post-use billing models
- Produce audit reports to support future product pricing negotiations
How to turn on RLM Report Logs
The is nothing that the ISV needs to do. The user creates an “options file” for each RLM ISV for which he wants to produce a log file, and adds this line to the file: REPORTLOG +file_path
Also, on the ISV line of the license file, the options file name must be specified.
Format (pre-RLM v9.0): ISV isvname isvname.exe isvname.opt
or
Format (RLM v9.0+): ISV isvname options=isvname.opt
Other RLM Report Log Features
- Plain-text format is fully documented
- Applications can ensure that report logs are capturing usage
- ROTATE [daily | weekly | monthly | #days ], automatic log file rotation
- Feature names mapped to “product names”
- Authentication to ensure report data integrity
- Anonymized – ensures user privacy
- ISVs can write their own report log records
- 3rd party RLM reporting tools are available from Reprise Software partners
For more information about RLM report log and its format specification, please review the RLM End User Manual.
Licensing a multi-featured product with RLM
Recently we received a common question from one of our customers looking for some advice.
The answer depends on whether the components are always released on separate schedules or as a group. If the former, then use a separate LICENSE line for each one. This allows them to have different attributes, such as version and expiration.
If the components are always released as a group, then they can be licensed with a single LICENSE, with the specific set of components authorized expressed in the "OPTIONS=" attribute of the license (example below).
If you choose the OPTIONS field route, then the value of the OPTIONS attribute can be retrieved using the RLM api call rlm_license_options(). This call returns the contents of the OPTIONS string so that your application can parse it to determine which features should be enabled.
Example: OPTIONS="pie bar scatter max_points=1000"
RLM License Generation Options
With the release of RLM v9 in December 2010, there are now three basic ways to generate licenses for your customers. Let's examine your options in order from the simplest to the most comprehensive.
RLMgen program
RLM v9 introduces a new graphical, web-based program for generating RLM licenses called RLMgen. RLMgen simplifies license generation by allowing your staff to interactively define products in terms of the kinds of licenses you want to enable them. Separate definitions can be created for eval/trials, periodic pricing models, and permanent licenses. License parameters that are common to most licenses can be defined to apply to all license definitions. Once defined, licenses can be generated by entering the number of licenses, an expiration date, and the customer's hostid.
RLMgen is especially useful for simple products were there is only one feature per product.
RLMsign Utility
If your products consist of multiple features per license, or if you need to incorporate license generation into your existing automated processes, then using the standard license generation tool provided with RLM could be right for you. This utility program called RLMsign, parses stored license templates then inserts a digital signature into each license that it finds. The result is a license file that is ready to send to your customer.
Since RLMsign can handle arbitrarily complex licenses in each template, it is particularly well suited to support modular products that are sold in an array of different configurations.
API call rlm_sign_license()
RLM also offers a call in the standard RLM SDK called rlm_sign_license() that signs individual licenses in memory. This call is useful when you need to create a custom application that generates licenses, or to integrate license creation into your existing back office infrastructure, when access at the source code level is required.
Search the Blog
Recent Posts
- Activation of a Rehostable license fails with a -148 (NO_REHOST_TOP_DIR) error
- Reprise Software’s Recommended Software Installation Steps
- Failover License Servers – why can’t I have 3?
- Application cannot connect to license server
- My license server won’t start
RSS feed subscription