Skip to main content

Running into an issue that honestly has me ready to pull out some of what little hair remains. ;)



Have an upgrade policy for a specific app which fails on MOST, but not all of our systems. I can't determine why.



Have a very simple package which simply places a large installer script into /private/var/tmp
Next, I'm running the install command via "Execute Command" under "Files and Processes".



Essentially, the package places a script in the location, which is then executed. The script itself is too large to deploy via Casper's normal script process (approx 7-8mb), thus this particular approach.



Now - in all of my initial testing, we had success. When deployed to production, on approximately 2/3 of the systems, I get the following in the logs when it attempts to execute the script:



Result of command:

/bin/sh: ./private/var/tmp/install.sh: No such file or directory


On the remainder, it executes perfectly.



I've tried both .dmg and .pkgs for the package, no change.



My main question - is "/private/var/tmp" a bad choice for temporary installers? Is there a "best practice" directory which would make more sense while I attempt to troubleshoot the issue?

I would probably use /private/tmp/, not /private/var/tmp/ myself.



Also, what could be in that script that would cause it to be 7-8 MBs? Would this happen to be a McAfee A/V installer script? Or something like that which contains a payload within the script contents?

Thanks mm2270.



Re: contents of the script... very good guess ;)
If you know of a better approach for this particular installer, I'm definitely all-ears! This is our 1st real attempt to push it out - it has been a notorious thorn in our side for quite a while.



I'll re-consider the /private/tmp option. Tweaking things and trying to get our success rate up...

Could be that I'm misreading but ./private/var/tmp/install.sh does not equal /private/var/tmp/install.sh
unless the script is changing directories and starting from the root of the drive.

Thanks @bpavlov . Sometimes a 2nd set of eyes makes all the difference. Refreshed the policy and so far I'm seeing 100% success on the machines that have checked in since.

Terms & ConditionsCookie settings