While activating a Universe/HP-UX site we realized that the license verification process may work differently depending on the OS user permissions. To explain this I thought I’d provide some insight into how our activation process works.

The process for all Nebula R&D products is similar, but here is how NEBULAXLITE works as an example:

• You load the NEBULA-RND account.
• You type NEBULAXLITE.ACTIVATE to generate request data. (Optional LANG=ES1 or LANG=FR1 provides results in Spanish and French respectively.)
• The code looks to the host OS for specific markers to uniquely identify the system. It does not look at data or even your site-specific filenames, only timestamps and other static metadata for files which are consistent on every system of a given OS type. Since each OS is unique, a special effort is required to port the activation code to a new OS, but we have most of them covered now.
• The markers are encoded into the NEBULAXLITE.REQUEST item along with a code to identify the DBMS type and OS type, and you send the request item to us.
• We generate a key, unique for all of this data, and we add an expiration date.
• At runtime, NEBULAXLITE.BUILD quickly gets the exact same system data, plus it decodes the key to do a comparison. On a successful match the expiry date is checked and the code progresses accordingly.

So, if you generate a request as user "root" you have permissions to get various OS markers. If you then generate a spreadsheet from a non-root user, that last validation process by NEBULAXLITE.BUILD may obtain less data, and thus, the data in the key won’t match the current runtime info from the OS.

The answer to this problem is to install NEBULAXLITE as a non-root user. In other words, install with a user ID that has the same permissions as users who will be generating reports. The activation request and runtime checks should then generate the exact same data. If this presents an issue for any of you, please let me know.

Some of you may not like activation processes like this but we need to protect our assets somehow. The process we use is typical of many products in our industry nd, and I’d rather not debate whether or not software should have security, this is simply a fact of life. Our goal was to make the process as simple as possible, while keeping everyone comfortable with this broad topic called "security".

Some of you may be thinking "hey, I wish I could do something like that for my products!" This activation process is used for all Nebula R&D products but is intentionally product/vendor independent. At some point it will be offered as a separate product, NebulaSecure, so that you can protect your software in exactly the same way – with no intervention on our part for providing or managing keys. Until then, the process will be refined internally, we’re working on reports to help us understand who has activations and when they expire, and I want to make sure this environment completely stable for all supported platforms.

An enhancement that I plan to make to this embedded NebulaSecure module is a web service interface that will allow developers to re-activate their systems without copy/paste and email. All you’ll need to do is enter NEBULAXLITE.ACTIVATE REMOTE and the process will be handled automatically. At this point the only thing that will put this feature higher on the priority list is if a VAR wants to activate 10 systems without going through the manual effort, but it’s coming…

Of course, comments and suggestions are always welcome – as well as requests for licensing of our software.