Wow, so finally got a chance to look at the postinstall.sh script. Wow. Just wow.
Wow, we were tasked with packaging/deploying the Blue Jeans Scheduler (drag n drop app; but need to suppress updates), which is pretty straight forward. Along the way we saw how incredibly convoluted the Blue Jeans app itself is distributed, and how the flat/signed PKG looks great, but includes two really bad scripts.
I wonder if Blue Jeans developers are split in two camps. One to make the PKG, and one to make the scripts.
Shows how two good teams split apart can make for one horribly designed deployment solution.
Blue Jeans should be ashamed. Oh, their dev team have been given a link to this thread.
Don
We had a BlueJeans (er, almost said WebEx!) session with Nelson, Sean and a couple others at BlueJeans to discuss deployment challenges.
Their Blue Jeans Scheduler for Mac.app product is distributed on a DMG (drag-installable) which is great, following Apple guidelines.
Their Blue Jeans.app product is also drag-installable, but is not distributed on DMG because there are some requirements that lead them down the road they followed. Such as minor updates requiring write access to /Applications/Blue Jeans.app, etc. Apparently user is not disrupted if minor updates are applied behind the scenes, but this requires user having write access to the app (a bad idea in every way), and major updates are more intrusive, they explained they notify people like us when those are released (not sure how that would pan out across so many client environments and teams!).
We asked for:
- Breakout of defaults commands so we can suppress updates, and pre-populate server info.
- Lift admin rights requirements for updates by leveraging /Library/Application Support/BlueJeans/.
- Provide enterprise customers with either DMG drag install only, or if a PKG is required it should have sound logic to be deployable with nobody logged in to the Mac (litmus test).
- Never expect users to have admin rights, but don't build fragile workarounds, instead leverage the built in domains in OS X to enable management.
Number 1 on the list (defaults) would hold us over so we can deploy, while they revisit their approach.
They are going to remove the empty pre-install script, and they plan to revisit the post-install script syntax (that contains bad logic, relies on a user being logged in). Hopefully they'll move to strictly drag-install and leverage what OS X offers for sustainability/manageability.
Thankfully this is a very receptive/approachable company, the discussion was great for all parties.
Don
So they're one of "those" developers that likes to drop an Applications folder in ~. I really hate that!
Wait, they use ~ in the script?!
@davidacland wrote:
So they're one of "those" developers that likes to drop an Applications folder in ~. I really hate that!
Yea, bad app design, flawed approach. Their team (4 were on the Blue Jeans session) admitted needing to get up to speed on Mac software distribution. I applaud them for being honest. Even while I lambast them a bit here on this forum (I provided the link).
They're a smart team, I'm sure they'll get up to speed fast. They're just not aware of Apple guidelines. Yet.
Wait, they use ~ in the script?!
Ya...did you see their beautiful pre-install script? :)
They seemed genuinely eager to get aligned with Apple's best practices. Fingers crossed they deliver.
Don
Um...hmmm....I'll ask the Blue Jeans developer to have another look at this thread... :)
Applying for freelance work at blueJeans....
Hey Guys, any new news since you started communicating with BlueJeans? We are considering switching to them from WebEx but I certainly don't want to be facing app deployment problems.
@KyleGDG they're working on the new version, not sure when we can expect the fixes/improvements. I'll let them know to revisit this thread.
@tnielsen bro, give them a call, you never know. :)
autopkg!
Maybe we'll get to the point where companies provide their own recipes rather than relying on the community to make them! If I were developing software, I'd probably be keen to provide our own recipes to make it as easy as possible to get the software to the end users.
Not sure the problems we identified can be fixed with AutoPKG. The developer has to change how their software works.
BlueJeans responded. They are aware but no ETA for changes.
Understand that. It was more the point that if you have to redevelop, then redevelop with simplified installation in mind. Look at how installs are done and use that as a base to provide an easy solution.
If it easily ties in with autopkg, then that would suggest you are on the right tracks!
Yes makes perfect sense. BlueJeans is a very responsive, approachable company. Hopefully they'll engage the JAMF Nation community. There is so much for them to gain.
@pbowden (Microsoft dev over on Slack) is a good example of how en engagement can help enhance a product, the community's perception, etc.
Hey guys, I am one of the developers at Blue Jeans.
@donmontalvo Thanks for all your great feedback. We are trying to incorporate it in our product. We have already cleaned up the pre and post install scripts in the pkg. We are still prioritizing the other feedback you provided. Enterprise app deployment is becoming very critical use case for us and we will be making progress in this area soon.
@KyleGDG Try us out! We will be certain to resolve any issues you face.
Hey guys, I am one of the developers at Blue Jeans.
@donmontalvo Thanks for all your great feedback. We are trying to incorporate it in our product. We have already cleaned up the pre and post install scripts in the pkg. We are still prioritizing the other feedback you provided. Enterprise app deployment is becoming very critical use case for us and we will be making progress in this area soon.
@KyleGDG Try us out! We will be certain to resolve any issues you face.
Thanks @donmontalvo May I ask how you are deploying despite these challenges? Were you able to find a method that works? Guessing until its fixed that the BlueJeans.app needs to reside in the ~/Applications/ folder, Blue Jeans Scheduler for Mac.app can reside in /Applications/ then do you also need Blue Jeans Launcher.app in /Applications/? Any other browser configs or ways you successfully got the Blue Jeans.app to run in the /Applications/?
Our users all have limited accounts on their macs and are bound to AD.
@adish Any chance you can provide a time frame for how long it might take you guys to complete the planned changes?
Thanks everyone!
@KyleGDG default location for now. That causes an inventory and management nightmare though but it's the only option right now.
@adish please don't forget the Blue Jeans Scheduler login items issue where each launch adds another login item to the user's list.
@KyleGDG @donmontalvo
- The latest pkg will install the Blue Jeans.app in /Applications and the app will run successfully from /Applications. No browser config is required.
- The Blue Jeans Launcher.app is a helper app we use to download and install the app. For individual users we use the Blue Jeans Launcher.app for a friendlier experience. For admin deploys, the .pkg is ready with the fixes suggest by Don.
- The concern with limited user accounts is receiving the smaller patch updates to the app. We are trying to fix this by leveraging /Library/Application Support/BlueJeans/, as suggested by Don. This is a bit tricky based on our framework and hence it is requiring more time.
- We have gotten mixed feedback on the major app updates, some admins want to roll out the updates and some want their users to be able to do it. We have a way to disable updates for an enterprise and then the admins can roll out the updates in a timely manner.
- We will also look into the Blue Jeans Scheduler login items issue soon.
@adish sorry for the delayed response, just coming up for air. Thanks for being responsive to the JAMF community. These are most welcome changes, to a solution that is picking up quite a bit of momentum in enterprise.
@donmontalvo The patch updates by leveraging /Library/Application Support/BlueJeans/ will be releasing in our next version in April 2016, so no issues for users with limited accounts :)
That's great news @adish. Looking forward to that. Have the issues been addressed with the Blue Jeans Scheduler.app? Namely that editing events in the app defaults to a different time zone and changes your meeting time? Also, multiple copies of the app appearing in startup items as indicated in @donmontalvo 's screenshot above?
Another thing I am keenly waiting for is when BlueJeans begins to report the correct software version number when selecting "get info" on the app. The JSS relies on this figure being accurate so we know when people should be getting updates.
@KyleGDG The issues you mentioned are currently being worked on. Unfortunately, I cannot commit to a date but will provide an update as soon as I have one.
@adish The version info should be a simple tweak of the Info.plist file in the application bundle:
For Blue Jeans Scheduler for Mac.app:
$ defaults read /Applications/Blue Jeans Scheduler for Mac.app/Contents/Info.plist CFBundleShortVersionString
1.0.204
$ defaults read /Applications/Blue Jeans Scheduler for Mac.app/Contents/Info.plist CFBundleVersion
1.0.204
For Blue Jeans.app:
$ defaults read /Users/jdoe/Applications/Blue Jeans.app/Contents/Info.plist CFBundleShortVersionString
1.6.153
$ defaults read /Users/jdoe/Applications/Blue Jeans.app/Contents/Info.plist CFBundleVersion
0.1
But yes, it does look like there is some strangeness to the version information, particularly the Blue Jeans.app application bundle. Notice the difference between CFBundleShortVersionString and CFBundleVersion strings for the app.
As @KyleGDG mentioned, we can't scope policies if we can't get accurate/reliable version information. :)
Don
@donmontalvo Thanks. This is helpful.
