We recently purchased a network lab license for a large university. We have 200 or so computers to install against. We use Casper and other management systems to build packages and push apps out. This usually includes bundling the license config info in with the app and distributing. Rhino for Mac appears to resist this process. When we package the app and bundle the network license portion the deployed packaged fails to trigger the network setting.
Thoughts?
Hi Chip,
Let me point out a few things and see if this helps you in any way.
1.) When you run Rhino the first time, it creates the following folders:
/Library/Application Support/McNeel/Rhinoceros/License Manager
/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses
Important: each of these folders is 'chmod' with +rwx so any user can write information to it.
2.) The Rhinoceros/License Manager/Licenses folder containās Rhinoās license file, which for Rhino for Mac is named 781b000c-8d0b-4ed3-8ead-213bdb848f39.lic. For standalone licenses, this file is encrypted, unreadable, and unique per system. For network licenses, though, this file is clear text, readable, and can be moved between one system and another.
3.) For systems that have a network license, you will also find a LicensesZooClient.settings file that exists in the Rhinoceros/License Manager folder. This file is also clear text, readable, and can be moved between one system and another. It contains the name of the Zoo server as entered into Rhino.
If your deployment system can also performs steps 1, 2, and 3, in addition to pushing the Rhino application bundle into each systemās Applications folder, then you should be able to deploy Rhino to all 200+ systems.
For more information on how Rhino for Mac finds a Zoo server, see the following:
https://wiki.mcneel.com/zoo/findzooservermac
Does this help?
ā Dale
Ahhh. Excellent. The .lic file may be the hang up. Our packaging system wasnāt retaining this or it is being over written on the destination machines. Weāll do some more testing and let you know.
We do have one question first. There is licensing information generated in the user account space. /Users/user/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses for instance as well as ā¦/Rhinoceros/MacPlugins ā¦/scripts and ā¦Template Files. The other ones seem straight forward but is anything being created in that /Users/user/Libraryā¦Licenses director that needs to be deployed somehow?
No, the user-profile specific folder:
/Users/~/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses
is not used for licensing.
(Something tells me that you are encountering a vestige of our pre-release Rhino for Mac beta - where we might have created this folder before we changed our system).
Iām trying to follow this documentation to get Rhino 5.1 deployed in our Mac labs. Iāve tried different combinations of permissions, also with and without the .lic file but Rhino either prompts to provide or buy a license. Is there something Iām missing or something else I can try?
If I install and activate Rhino manually, then attempt to re-install on the same system by moving the same files back into place then Rhino crashes immediately.
Also, this page appears to have a typo in the name of the .settings file.
http://wiki.mcneel.com/zoo/findzooservermac
And in the xml comment that Rhino generates, āwrittenā is misspelled āwritenā.
Hi Hansen,
There is not a easy way to deploy Rhino for Mac licenses as standalone because the licenses file are unique per system. See my reply above for details.
Your best bet for deploying Rhino for Mac is to have it licenses as a network node, requiring a Zoo license server.
http://wiki.mcneel.com/zoo/home
To do this:
1.) Get your Zoo server up and running, and add your license key(s) to the Zoo.
2.) Install Rhino for Mac as a network node - a installation that uses the Zoo.
3.) Perform whatever network troubleshooting to make sure Rhino can get its license from your Zoo.
4.) Deploy Rhino for Mac.
5.) Copy the license file from the āmodelā system to the other systems using the information presented above.
Does this help?
Yes, we are using network licenses and a Zoo server. Iām still finding the deployment to be somewhat finicky but I believe Iāve nearly got it ready. It took me a while to figure out the issue with the typo in the .settings file.
Within the .lic file, Iām noticing that the PluginID value guid/uuid changes per installation. I assume that it is okay to deploy this with any static value?
Yes this is okā¦
@hansen_m Your note does not specifically call out how you are doing managed installation, so Iām going to make some assumptions here.
First off, weāve had no issues with creating a monolithic master image, whereas Rhino has been Zoo licensed on the master, imaged up with deploystudio, and imaged down with deploystudio.
However, based on past permissions issues such as this, weāve moved to a model in public lab spaces where our āauthenticatedā users are working within a common local account - the same account in which Rhino (all apps) was installed and licensed into on the master. Smooth sailingā¦
Assuming you are using a different method, i.e., login hook/copy master template accountant, etcā¦that is where we used to see frequent enough permission issues with some apps/versions, breaking certain functionality. Not fun!
If this is you, our blanket recourse would be: find every template user account file/directory related to the app and set such to RW/everyone on the master.
Conversely, if you are pushing, do something similar to those user account pushed elements.
After similar issues in past, Iāve had other company tech support tell me they do not āsupportā bla bla, only to see the problem go away in future versions. Knowing McNeel (not being as described) if you can narrow down the source under your specific method, I guess theyād try to fix it, if possible.
Richard,
Thanks for the reply. I can try to share a little bit more about how we deploy apps in our environment. Due to the large number of machines we manage, security and privacy policies we try to enforce, number of apps we deploy and by trying to keep things as flexible and dynamic as possible we build all of or systems from a vanilla base, with unique user ldap accounts, and layer individual applications on top of that base.
I actually just finished this and was able to successfully deploy it to our labs a few days ago. We deploy hundreds of software packages, and while this certainly wasnāt one of the worst ones there are still some ways it could be easier for us to maintain. My personal feeling is that if we can work with the vendor to provide the best possible experience for students using the the software then the students are more likely to be successful in the labs and also either continue to use the software in their careers or recommend it to others. But if software is difficult to deploy it usually ends of being deployed poorly and causing end users to get a bad impression of both the vendor software and the computer labs.
This snippet is written in the action script language from our software distribution system but I think you can get the gist of how it is actually installed on the client systems.
delete "/tmp/Rhinoceros.dmg"
move "__Download/Rhinoceros.dmg" "/tmp/Rhinoceros.dmg"
wait /bin/sh -c "/usr/bin/yes | /usr/bin/hdiutil attach -nobrowse -mountpoint /tmp/Rhinoceros /tmp/Rhinoceros.dmg > /dev/null"
continue if {exists folder "/tmp/Rhinoceros/Rhinoceros.app"}
if {exists folder "/Applications/Rhinoceros.app"}
wait /bin/rm -rf "/Applications/Rhinoceros.app"
endif
wait /bin/cp -Rfp "/tmp/Rhinoceros/Rhinoceros.app" "/Applications"
wait /usr/sbin/chown -R root:admin "/Applications/Rhinoceros.app"
wait /usr/bin/hdiutil detach -force "/tmp/Rhinoceros"
delete "/tmp/Rhinoceros.dmg"
if {not exists folder "/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses"}
wait /bin/mkdir -p "/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses"
endif
createfile until __END
<?xml version="1.0" encoding="utf-8"?>
<!--Zoo client settings file writen by Rhino-->
<ZooClient>
<Software_McNeel_Rhinoceros_5.0_License_Manager Server="ourzoolicenseserver.fqdn.psu.edu" />
</ZooClient>__END
delete "/Library/Application Support/McNeel/Rhinoceros/License Manager/LicensesZooClient.settings"
move __createfile "/Library/Application Support/McNeel/Rhinoceros/License Manager/LicensesZooClient.settings"
// Create GUID
wait /bin/bash -c "/usr/bin/uuidgen > guid.txt"
createfile until __END
<ZooLicense xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/ZooCommon"><Data><Capabilities>NoCapabilities</Capabilities><DateAdded i:nil="true" /><DateToExpire i:nil="true" /><LicenseCount>1</LicenseCount><LicenseTitle></LicenseTitle><ProductLicense></ProductLicense><RegisteredOrganization></RegisteredOrganization><RegisteredOwner></RegisteredOwner><SerialNumber></SerialNumber><TextMask i:nil="true" /></Data><Header><BuildType>Unspecified</BuildType><LicenseId>REMOVED_LICENSE_ID_GUID_FOR_PUBLIC_POST</LicenseId><LicenseInstance>0</LicenseInstance><PluginId>{line of file "guid.txt"}</PluginId><ProductId>781b000c-8d0b-4ed3-8ead-213bdb848f39</ProductId></Header><NodeType>Network</NodeType><Owner>{hostname}</Owner><Status><DateAssigned i:nil="true" /><DateToExpireCheckOut i:nil="true" /><DateUpdated i:nil="true" /><Sessions xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" /><StateType>Available</StateType><User><HostName></HostName><ProcessId>0</ProcessId><UserName></UserName></User></Status></ZooLicense>__END
delete "guid.txt"
delete "/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses/781b000c-8d0b-4ed3-8ead-213bdb848f39.lic"
move __createfile "/Library/Application Support/McNeel/Rhinoceros/License Manager/Licenses/781b000c-8d0b-4ed3-8ead-213bdb848f39.lic"
Thanks for the insight into your process. Your snippet reminds me of the ābad old daysāā¦
We are too far removed to ascertain anything directly helpful re Rhino Mac / Zoo. As I assume you are well aware, for us, managed deployment issues were typically always resolved by hunting down a permissions flag somewhere, that had been affected by the deployment for one reason or another, whereas the vendor had not anticipated such. That was essentially my 2-cents.
We are still conceptually similar to your standard approach with our faculty/staff deployments: we are using Casper however. Conceptually similar for Win labs too - Zenworks. For the Mac labs, weāve gone back-to-the-future (unconventional) and have been pleased. All deployment issues vanished. Our users could not be happier. I can understand how our approach may not be suitable for your environment. I get where you are coming from.
What we did was cobble together assets to provide security, etc., we need to enforce. We lost single sign-on in the process, but we discovered that our users could care less. They love the end result. I will say that incremental changes are not the easiest. If you need constant flexibility during the semester, this approach may be more trouble than it is worth.
We use a NAC (it targets these Mac lab IPs) to know who is hitting the network, PaperCut for print access, Deep Freeze for system integrity, etc. Theoretically, a student could be present for a Rhino class and never log-in. As soon as they try and hit the network (we exude license servers and such things) they are prompted for credentials. Same if they want to print or access their network share.
Issues essentially permanently vanished, initial sign-on is instant, and everyone seems happy. Like everything though, nothing is perfect.