i've dealt with there stuff before... it's a "lovely" installer ....
there are many issue i have with it... (system-wide vs per user installs, etc...)
we are up to version 3.6.1 over here now

What i ended up doing is extracting the base package using pacfist,
then packaging it up (with Packages) with my own pre and post flight scripts...

Hi @kstrick, that's what usually happens when we have to create a package from a heap of smelly code. :)

If you don't mind my asking, what did you do in your pre/post flight scripts?

Here's what i've been doing, seems to work pretty well....

I got into their installer app (grrr... installer apps...) and I pull out their .mpkg...
I open it with Pacifist and extract the asperaconnect.pkg

I then go into Packages,
and i throw the package in the 'Additional Resources' area of the 'Scripts' tab....
then attach the two scripts below.

The first script removes older versions that exist either User-wide or System-wide...
second script just installs the package.

Preinstall Script

#!/bin/bash



killall asperaconnect

killall asperacrypt

sleep 2



rm -rf /Library/Internet Plug-Ins/Aspera Web.plugin 2> /dev/null

rm -rf /Library/Internet Plug-Ins/Aspera Web.webplugin 2> /dev/null

rm -rf /Library/Internet Plug-Ins/Aspera Web* 2> /dev/null

rm -rf /Library/Application Support/Aspera/Aspera Connect 2> /dev/null



for EXISTING_USER in $(/bin/ls /Users | sed -e '/Shared/d' -e '/Deleted Users/d' -e '/.localized/d' -e '/.DS_Store/d' -e '/.com.apple.timemachine.supported/d' -e '/Adobe/d' -e '/Library/d');

do

    rm -rf /Users/${EXISTING_USER}/Library/Internet Plug-Ins/Aspera Web.plugin 2> /dev/null

    rm -rf /Users/${EXISTING_USER}/Library/Internet Plug-Ins/Aspera Web.webplugin 2> /dev/null

    rm -rf /Users/${EXISTING_USER}/Library/Internet Plug-Ins/Aspera Web* 2> /dev/null

    rm -rf /Users/${EXISTING_USER}/Library/Application Support/Aspera/Aspera Connect 2> /dev/null

done



exit 0

Postinstall Script

#!/bin/bash



# Determine OS version

osx_vers=$(sw_vers -productVersion | awk -F "." '{print $2}')



# Determine working directory



install_dir=`dirname $0`



if [[ ${osvers} -lt 7 ]]; then

sudo installer -dumplog -verbose -pkg "$install_dir/asperaconnect.pkg" -target /



else

sudo installer -allowUntrusted -dumplog -verbose -pkg "$install_dir/asperaconnect.pkg" -target /

fi



exit 0

Thanks @kstrick, your feedback is awesome! I finally had a chance to circle back and work on this.

I took what you provided and tweaked it a bit. The PKG is deployable in its current state (I do remember it being distributed as an *.app in the past). I'm also a HUGE fan of Packages.app, fortunately it isn't needed for this twist on your idea. Basically deploy the native PKG but run a cleanup script first (see below, now it may not be needed).

1. Download the PKG, it seems to be a flat/signed deployable PKG now, and upload to JSS.




2. Create/upload pre-installation script (below), have it run Before.

#!/bin/bash

#

################################################################

# Adapted from a script posted on JAMF Nation:

# https://jamfnation.jamfsoftware.com/discussion.html?id=17091

# 20151018 DM

################################################################



# Variables

Existing_Users=`dscl . list /Users UniqueID | awk '$2 > 500 { print $1 }'`



# Kill processes

/usr/bin/killall asperaconnect 2> /dev/null

/usr/bin/killall asperacrypt 2> /dev/null



# Sleep

/bin/sleep 2



# Forget receipts

/usr/sbin/pkgutil --forget com.aspera.AsperaWeb 2> /dev/null

/usr/sbin/pkgutil --forget com.aspera.connect 2> /dev/null

/usr/sbin/pkgutil --forget com.aspera.crypt 2> /dev/null



# Remove local level stuff

/bin/rm -rf /Applications/Aspera Connect.app 2> /dev/null

/bin/rm -rf /Applications/Aspera Crypt.app 2> /dev/null

/bin/rm -rf /Library/Internet Plug-Ins/Aspera Web* 2> /dev/null

/bin/rm -rf /Library/Application Support/Aspera/Aspera Connect 2> /dev/null



# Remove user level stuff

for u in $Existing_Users

do

    /bin/rm -rf /Users/"$u"/Applications/Aspera Connect.app 2> /dev/null

    /bin/rm -rf /Users/"$u"/Applications/Aspera Crypt.app 2> /dev/null

    /bin/rm -rf /Users/"$u"/Library/Internet Plug-Ins/Aspera Web* 2> /dev/null

    /bin/rm -rf /Users/"$u"/Library/Application Support/Aspera/Aspera Connect 2> /dev/null

    /bin/rm -rf /Users/"$u"/Library/Receipts/com.aspera.* 2> /dev/null

done



exit 0

As a side note, the developer seemed to be welcome to input. Version 3.6.1 appears to default to local level install. Users who run it in Finder will be prompted for admin credentials, whereas hitting Change Install Location... will first warn them with an error:

Non admin user error

...if user clicks Install for me only the error goes away, and it installs into user's home directory.

Non admin user error

Not very intuitive...provided more feedback to developer.

Another note, the developer added logic to the 3.6.1 installer so user level stuff installed before gets removed, before installing at the proper local level. So the above script is probably moot, but will keep it in the policy to be sure. ;)

HTH,
Don

Apparently I'm not the only one thanking them (@gregneagle). :)

Cool, glad to a package now instead of an installer app...

Maybe that they are now owned by IBM, and IBM is now tight with apple, we will continue to see nice things :)

Public lambasting does a vendor good...behold a system wide PKG.

@donmontalvo W00t!

i guess the question i have is will we consistently get these, and how far will you have to dig to find them...
(the standard connect is at least a package now, but not system wide)

Hopefully that page will be the go-to for 3.6.x.

Well...they almost got it right. If the server is at an older version than the plug-in, it complains.

But, dismiss the Download Aspera Connect window (click the "x") and everything works fine.

Seems like a server side issue, I'll ping the team that handles that...

ugh, reminds me of some Silverlight issues i've had...

OK, so Aspera busted my bubble...still a number of issues with this "system-wide" installer PKG.

Not sure who the genius was who decided to rename the plug-in to /Library/Internet Plug-Ins/Aspera Web 3.6.1.111259.plugin but I'm not sure that was a great idea.

Especially if your postinstall script looks for an entirely vanilla naming convention for removing old versions of the plug-in and apps from ~/Applications and ~/Library/Internet Plug-Ins.

So, no, the old stuff does not get removed by the "system-wide" installer PKG. Good thing I kept our SubsidizeAsperaDevTeamByCleaningUpTheirMess.sh script to run before the PKG is installed.

I'm convinced IBM's internal dev team are Windows folks totally winging it on the Mac side...too bad they don't report to Fletcher Previn, or this would have been polished long ago. :(

Oh...I forgot to include this Suspicious Package screenshot of their "system-wide" PKG...in case you're at the water cooler and need to share a laugh...

Thanks to JeremyH at Aspera support, we now know that both the "Internal" and Release" version information is stored in /Applications/Aspera Connect.app/Contents/Resources/product-info.mf.

I took a stab at coming up with an Extension Attribute to pull the "Release" version...any scripting gurus know how to make this command less fugly? :)

cat /Applications/Aspera Connect.app/Contents/Resources/product-info.mf | grep '<version>' | head -n 1 | cut -d " " -f3- | tr -d "<version>" | tr -d '/'

Looks like I'll be calling Aspera again tomorrow...seems like the preinstall script (still) tries to traverse through existing home directories...including root home directory if the policy is running while the user is logged on...

echo removing local user plugin 

rm -rf ~/Library/Internet Plug-Ins/Aspera Web.plugin 

rm -rf ~/Library/Internet Plug-Ins/Aspera Web.webplugin 

rm -rf ~/Library/Internet Plug-Ins/Aspera Web*

Which causes this error...which Aspera's support page says is due to... the PKG unable to get into home directory/ies.

Lets hit this out of the park, right?

PS, a snapshot seems to do the trick, if you run a script to remove old versions and flush receipts...ugh.

Don

@donmontalvo Can you post a sanitized version of what cat /Applications/Aspera Connect.app/Contents/Resources/product-info.mf outputs? If we can see how its structured, I'm sure we can likely help come up with a more sane way to grab the version info. I'm not bothering to install this... thing on my Mac I like my Mac too much to punish it in such a way :)

Here ya go, according to Aspera support, this is where they've been storing the version information. Not sure why they don't put it into /Applications/Aspera Connect.app/Contents/Info.plist.

The first "Version" is "Release" version, the one that matches the version on the download page. The second "Version" is the "Internal" version which we don't need.

$ cat /Applications/Aspera Connect.app/Contents/Resources/product-info.mf

<product>

  <name>Aspera Connect</name>

  <version>3.6.6.119698</version>

  <components>

    <component>

      <name>ascp</name>

      <version>3.5.6.112424</version>

    </component>

  </components>

</product>

As long as the structure of that .mf file doesn't change from one version to the next (only the version string within it), then the following should work to pull the version into an EA:

#!/bin/sh



productinfo="/Applications/Aspera Connect.app/Contents/Resources/product-info.mf"



if [ -e "$productinfo" ]; then

    version=$(awk -F'>|<' '/<version>/{print $3; exit}' "$productinfo")

    echo "<result>$version</result>"

else

    echo "<result>N/A</result>"

fi

If that file's structure changes at all, the above could break though.

Wow...baaaaaad flashbacks...

I remember suffering through Aspera Connect installer issues back at CNN. Nice to see them continuing the legacy... :P

One small note on the complaints about connect components having different versions: this is actually by design. Each of the components is built on a separately build/tool chain and it is common/intentional that Connect.app, Crypt.app and the .plugin have different version numbers within the Connect package. Realize this is confusing from the outside looking in, but it is as intended.

Michelle

@michellem understood but version information belongs in the appropriate Info.plist file for example /Applications/Aspera Connect.app/Content/Info.plist.

Read through the thread, the version information in that/those files is a mess. So enterprise admins have to deal with the sloppy coding, or to put it in a nicer way, the developer has to brush up on his Mac coding skills. :)

I see you just joined the forum, maybe you are from IBM? If so welcome! Hope our whining can result in some minor changes to help us deploy Aspera Connect with fewer headaches. :)

Don

@mm2270 I'll test mañana. :)

@mm2270 works like a charm...and btw, JeremyH at Aspera Support noted the "Release" version has been in that spot for quite some time. Hopefully that means it'll stay there...unless they add it to the /Applications/Aspera Connect.app/Content/Info.plist where it belongs. ;)

$ /tmp/test2.sh 

<result>3.6.6.119698</result>

PS, I forgot to mention, you saved 0.006s of my life, that's worth a JNUC beer. :)

$ time cat /Applications/Aspera Connect.app/Contents/Resources/product-info.mf | grep '<version>' | head -n 1 | cut -d " " -f3- | tr -d "<version>" | tr -d '/'

3.6.6.119698



real    0m0.010s

user    0m0.007s

sys 0m0.019s

$ time awk -F'>|<' '/<version>/{print $3; exit}' "/Applications/Aspera Connect.app/Contents/Resources/product-info.mf"

3.6.6.119698



real    0m0.004s

user    0m0.002s

sys 0m0.002s

$

@michellem wrote:

One small note on the complaints about connect components having different versions: this is actually by design. Each of the components is built on a separately build/tool chain and it is common/intentional that Connect.app, Crypt.app and the .plugin have different version numbers within the Connect package. Realize this is confusing from the outside looking in, but it is as intended.

Michelle

Putting together a summary for JeremyH at Aspera Support. Olive branch sent to @michellem to connect with Aspera's internal dev folks, to see if we can get proper versioning put into the Info.plist files for each app and the plugin. :)