Tweet
We recently received a C1 (concurrent) license for LifeScope. "Free" for a year because we have a 5500. What follows are my comments concerning the licensing part of LifeScope.
First I should state up-front that I generally hate licensing schemes. They always seem to have limitations and cause a bunch of implementation headaches. After spending the better part of a couple days with it, LifeScope's licensing (provide by a company called Flexera) just made my dislike of licensing even stronger. I point out that LifeTech's support people (Aditya and Darryl) have been very nice to work with.
1) There are two parts to LifeScope's servers -- the licensing manager and the lifescope manager. These can be run on different machines however in order to do so you must rip down any firewall between the two machines. The licensing manager uses port 27000 plus another random port (I have seen ports in the 46550 to 60704 range). My sysadmin is irritated about this state of affairs. :-(
2) How the licensing actually works was not very clear to me. It turns out that the license is only used while a person is actually in the lscope shell or GUI. A project/analysis can stay queued up or be actively running without needing a license. You need a license to do the initial queuing (since you will need to run the shell, run commands to set up the project/analysis, and then exit the shell) and to view the status of an analysis (once again the shell needs to be run momentarily). However it is, in theory, possible to have many people using a 5-user license if they are polite and do not stay logged into the shell. In practice I will have to see how well this works.
3) As an administrator, one very irritating feature is that the license manager does not show me who is using the license. All it shows is the number of licenses in use plus the installation username (not the actual person using the license), lifescope node, and port. The latter are not very useful in determining whom to call up in order to get a license released.
4) It seems like, although I can not re-create this problem consistently, that if a crash occurs when someone is logged in using the license then the license does not get released.
5) While there a ways around this, lscope allows and just as important the documentation consistently emphasizes putting your password on the command line. E.g., the docs say over and over:
# log into the shell
lscope.sh shell -u username -w password
Perhaps obviously when doing the above the password will be exposed to anyone on the system. The installation verification scripts also expose the password (a bug report is into LifeTech about this; I was not the first one burnt!)
6) One of the ways to avoid having the password on the command line is to create a file with a MD5 hash of the password. Unfortunately this file either needs to be in each project's directory or explicitly specified on the command line. Ditto for the user name -- it needs to be explicitly specified on the command line. In my mind a 'home dot' file (ala, ssh or vnc or any of the other numerous programs written through the last 40 years) that is picked up automatically would be a better method to do username/password (with overrides on the command line, of course).
Overall #1 is a bug, #2 could be made more clear in the EULA, #3 is a bug that might be overcome by user-training, #4 needs more testing, #5 is user-training plus a suggested edit of the docs, #6 is a feature request that would alleviate #5.
First I should state up-front that I generally hate licensing schemes. They always seem to have limitations and cause a bunch of implementation headaches. After spending the better part of a couple days with it, LifeScope's licensing (provide by a company called Flexera) just made my dislike of licensing even stronger. I point out that LifeTech's support people (Aditya and Darryl) have been very nice to work with.
1) There are two parts to LifeScope's servers -- the licensing manager and the lifescope manager. These can be run on different machines however in order to do so you must rip down any firewall between the two machines. The licensing manager uses port 27000 plus another random port (I have seen ports in the 46550 to 60704 range). My sysadmin is irritated about this state of affairs. :-(
2) How the licensing actually works was not very clear to me. It turns out that the license is only used while a person is actually in the lscope shell or GUI. A project/analysis can stay queued up or be actively running without needing a license. You need a license to do the initial queuing (since you will need to run the shell, run commands to set up the project/analysis, and then exit the shell) and to view the status of an analysis (once again the shell needs to be run momentarily). However it is, in theory, possible to have many people using a 5-user license if they are polite and do not stay logged into the shell. In practice I will have to see how well this works.
3) As an administrator, one very irritating feature is that the license manager does not show me who is using the license. All it shows is the number of licenses in use plus the installation username (not the actual person using the license), lifescope node, and port. The latter are not very useful in determining whom to call up in order to get a license released.
4) It seems like, although I can not re-create this problem consistently, that if a crash occurs when someone is logged in using the license then the license does not get released.
5) While there a ways around this, lscope allows and just as important the documentation consistently emphasizes putting your password on the command line. E.g., the docs say over and over:
# log into the shell
lscope.sh shell -u username -w password
Perhaps obviously when doing the above the password will be exposed to anyone on the system. The installation verification scripts also expose the password (a bug report is into LifeTech about this; I was not the first one burnt!)
6) One of the ways to avoid having the password on the command line is to create a file with a MD5 hash of the password. Unfortunately this file either needs to be in each project's directory or explicitly specified on the command line. Ditto for the user name -- it needs to be explicitly specified on the command line. In my mind a 'home dot' file (ala, ssh or vnc or any of the other numerous programs written through the last 40 years) that is picked up automatically would be a better method to do username/password (with overrides on the command line, of course).
Overall #1 is a bug, #2 could be made more clear in the EULA, #3 is a bug that might be overcome by user-training, #4 needs more testing, #5 is user-training plus a suggested edit of the docs, #6 is a feature request that would alleviate #5.
Comment