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

Reuti reuti at staff.uni-marburg.de
Fri Oct 31 12:55:36 GMT 2008


Hi Mark,

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.

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

-- Reuti


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




More information about the gridengine-users mailing list