The matlab software product requires a license to work. When a matlab process begins it checks for a license. If it cannot successfully obtain a license the matlab functionality will not work. Access to a license can be done via a tcp connection to a licensing server, or a the presence of a license file. When using a license file the following restrictions occur:
- Software is installed onto individual computers and does not use a network. Because this is a Named User option, the right-to-use privilege is assigned by your organization to a specific person. The designated Named User may install and use the software on a number of computers. These can include work, home, lab computers, and laptops, as long as the licensed Named User is the only person to use the software on each computer.
- Software is installed on one particular computer and does not use a network. The right-to-use privilege is available for non-simultaneous use by multiple people.
In a cloud env like OOI's execution engines, the user would likely have a license at their home institution which they would want to use. It seems less feasible to provide a stand alone license to either every user or every machine in a elastic env and potentially expensive or unruly to have a license for every registered user of the system.
Licit is the approach to federated software licenses prototyped by Munindar's group. It is a well thought out process for managing software licenses in a federated environment with a prototype implementation that mocks an environment. Its is not yet a completed software package ready for use with matlab in cloud envs. It has not yet been run in such a way that it actually checks out matlab licenses. A significant amount of additional development would is needed for it to be used with execution engines.
For licit to work with matlab the licensing process would have to be circumvented in one of the following ways:
- have a dummy license server that always says yes
- install a license on the VM when a matlab process is dispatched.
- the verification process in the matlab software would have to be disabled
- the checkout from the FlexNET server would have to be done on the user behalf and then replayed to the client side processes.
While the above list does sounds like dubious Licit does not overuse the license, it just takes on the role of enforcement. Because Licit itself would do the enforcement the agreement wrt to the number of active license at once would be in tact. However this probably still requires a deep read and understanding of the licenses agreement and/or an explicit blessing from Mathworks.
In some capacity Licit needs to work cooperatively with the home institutions licensing server/policies. It needs to be given information about the license server and the ability to access it on behalf of the end user prior to a user run. In the worst case this would require home institution sysadmin intervention, eg: if the license server is behind a firewall.
A user case is given to illustrate the problems at hand.
A scientist from 'UX', a new university previously unknown to the OOI system, acquires access to the system and wishes to run a matlab process. Via her faculty appointment at UX she has a license to use matlab, however the matlab license server is behind a strict firewall. She can easily run matlab code on UX machines, but wants to take advantage of the datasets within OOI. The sysadmin team at UX is very hesitant about opening up firewall ports and not very interactive with outside systems.
Is this a situation we want to support? The issues explored in Licit thus far will not help with this situation.
Having a firewall between the location of the matlab code and the license server is a somewhat familiar problem. The common solution is to setup a TCP tunnel with ssh allowing the users matlab code to tunnel through the firewall to the users home account and from there contact the license server.
If the Licit process is adapted we may still want to solve this situation so that we can support users that dynamically join the system yet have no control over their home institutions network policies.
We could design and create a TCP tunneling service for cloud and execution engine environments. This would allow not only for matlab and/or licit processes to contact license servers within the users home institutions but possibly other services as well. In summary the service would do the following:
Run at a point on the network where code in the execution environment can contact it, and where a process from the users home institution can contact it via TCP. The user would run an agent process in their home account which would poll our service for information about TCP tunnels that it should form. When told to by our service this agent will form a connection to the service with and a TCP tunnel. This connection must be securely formed. The existence of this tunnel will be recorded in the cloud services as a resource. Now when a user goes to submit a job that requires access to a matlab server, that job will not be scheduled until the TCP tunnel/matlab server resource can be acquired