[GE users] qlicserver: Managing license on a per server basis

Olesen, Mark Mark.Olesen at emcontechnologies.com
Fri Oct 31 13:11:14 GMT 2008


Hi Reuti,

> we only had to use FlexLM at some point in the past with site
> licenses, so I don't know whether it applies to your setup also: I
> copied both license files we got into one file and used only one
> FlexLM daemon.

Actually we have the opposite problem. We really need some form of
separation, since the vendor and daemons are the same, but the newer
application version will crash if fed older license keys. We want to
separate things.

As an addendum to my last mail: the "mapFrom" probably wouldn't work on
a port-by-port basis. The remapping would need to be on a server basis.
Would this be too restrictive? Do I also need to track and remap on a
port/server basis?

> I don't know, whether it can still be done to serve different vendors
> and types of licenses with one file.

Combining everything in one huge file still works, but is generally
inadvisable. Separate files give you better granularity and reduce the
chances of crashing all of the licenses for the entire company if a
'lmreread' fails after updating some vendors. 

/mark

> Am 31.10.2008 um 13:43 schrieb Olesen, Mark:
> 
> > We now have the situation in which we must distinguish between two
> > types
> > of FlexLM licences for a particular vendor. A set of leased licenses
> > supports the newest version of the application, while a set of
> > purchased
> > licenses only works for somewhat older versions.
> >
> > It seems that it is thus time for the qlicserver code to learn
> > where its
> > licenses are actually being served from.
> > I presume that there are other people with similar issues. Before I
> > rewrite stuff, I would like to find a solution that works for most
> > people and get your opinions.
> >
> > What I currently have and/or plan to have:
> > Instead of specifying the complex for my annoying application like
> > this:
> >
> >   <resource name="app" served="SOME_FEATURE"/>
> >
> > I would introduce a remapping field to specify a renaming from
> > particular servers. Simply adding an id number is the easiest
> example:
> >
> >   <resource name="app1" served="SOME_FEATURE"  mapFrom="serv1"/>
> >   <resource name="app2" served="SOME_FEATURE" mapFrom="serv2
> serv3"/>
> >
> > ... and rejoin as a derived complex:
> >
> >   <derived name="app">
> >     <element>app1</element>
> >     <element>app2</element>
> >   </derived>
> >
> >
> > Would people require a regular expression or glob syntax instead of
> > simply listing the server names in the new 'mapFrom' field?  Or
> would
> > this just be more confusing?
> > I do know that a "*" match is definitely NOT required, since I could
> > have easily just written the above example as follows:
> >
> >   <resource name="app1" served="SOME_FEATURE" mapFrom="serv1"/>
> >   <resource name="app2" served="SOME_FEATURE"/>
> >
> > Are there any usage cases this would be a problem?
> > Are there better names than 'mapFrom'?
> >
> > Note that since the "app" resource is now derived from the other
> > two, it
> > obviously cannot appear as a self-contained resource too. That means
> > that something like this:
> >
> >   <resource name="app1" served="SOME_FEATURE"  mapFrom="serv1"/>
> >   <resource name="app" served="SOME_FEATURE"/>
> >   <derived name="app">
> >     <element>app1</element>
> >   </derived>
> >
> > Would not and should not work. I think this is okay - since I don't
> > know
> > what that should really mean anyhow. However, with this approach
> (and
> > with the current qlicserver implementation), I think that both
> "app1"
> > and "app2" might be need to be managed complexes for any of this too
> > work.  This doesn't disturb me, since I really need to get at both
> > "app1" and "app2", but I don't know if this is a problem for other
> > people. Do we need to a hide any of these components?
> >
> >
> > I look forward to hearing your opinions.
> >
> > /mark
> > This e-mail message and any attachments may contain
> > legally privileged, confidential or proprietary Information,
> > or information otherwise protected by law of EMCON
> > Technologies, its affiliates, or third parties. This notice
> > serves as marking of its "Confidential" status as defined
> > in any confidentiality agreements concerning the sender
> > and recipient. If you are not the intended recipient(s),
> > or the employee or agent responsible for delivery of this
> > message to the intended recipient(s), you are hereby
> > notified that any dissemination, distribution or copying
> > of this e-mail message is strictly prohibited.
> > If you have received this message in error, please
> > immediately notify the sender and delete this e-mail
> > message from your computer.
> >
> >
> > --------------------------------------------------------------------
> -
> > To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> > For additional commands, e-mail: users-help at gridengine.sunsource.net
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

This e-mail message and any attachments may contain 
legally privileged, confidential or proprietary Information, 
or information otherwise protected by law of EMCON 
Technologies, its affiliates, or third parties. This notice 
serves as marking of its "Confidential" status as defined 
in any confidentiality agreements concerning the sender 
and recipient. If you are not the intended recipient(s), 
or the employee or agent responsible for delivery of this 
message to the intended recipient(s), you are hereby 
notified that any dissemination, distribution or copying 
of this e-mail message is strictly prohibited. 
If you have received this message in error, please 
immediately notify the sender and delete this e-mail 
message from your computer.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list