Appreciate your help but that failed. No pkg ever hit the machine.
Here is the actionscript:
//**Begin Preparation Marker
// Download all specified files
begin prefetch block
add prefetch item name=CC0B6527F1CF1410489EFED330AEE381A07DDACD sha1=cc0b6527f1cf1410489efed330aee381a07ddacd size=2257778 url=SWDProtocol://127.0.0.1:52311/Uploads/CC0B6527F1CF1410489EFED330AEE381A07DDACD/RoamingClient_MAC_2.0.39_custom0706.pkg.bfswd sha256=bcacba283510cc4dc9224dac101b4f86d1f0571ceb3436fb2716543f46bc64d7
end prefetch block
// All SWD files will go into a folder in the clients __BESData folder. This folder gets cleared on every restart.
parameter “baseFolder” = “__Download/”
// Move files into subfolders and unescape file names
move “__Download/CC0B6527F1CF1410489EFED330AEE381A07DDACD” “{parameter “baseFolder”}RoamingClient_MAC_2.0.39_custom0706.pkg”
// Log setup
parameter “mainSWDLogFolder” = "{parent folder of client folder of current site}/__Global/SWDDeployData"
folder create "{parameter “mainSWDLogFolder”}"
parameter “logFile” = “SWD_DeploymentResults.log”
//**End Preparation Marker
parameter “logFolder” = "{parameter “mainSWDLogFolder”}"
folder create “{parameter “logFolder”}”
// Run setup process
delete __createfile
delete run.sh
createfile until end
cd “{parameter “baseFolder”}”
// See comments at the beginning of this action for an explanation of the comment markers.
echo $(date +%Y_%m_%d" "%T) >> "{parameter “logFolder”}/{parameter “logFile”}"
echo Action ID: {id of active action} >> “{parameter “logFolder”}/{parameter “logFile”}”
I used Software Distribution>Manage Software Distribution from the bigfix console. I then uploaded a pkg (wizard) and created a task. I did not change any actionscript (other than what you suggested)
Yes the Orginfo.plist is part of my package. So to clarify - I have a custom pkg which places the plist in the correct location.
This pkg works natively in MacOS
I want to test this pkg in a current logged on user environment (users have admin rights and can install software) to see if it behaves the way it should on delivery but need clairty on what I need to put in the automated action script (that gets created when you upload a Pkg) and where it goes.
I played with runas=currentuser on macOS recently and found it a bit weird. If memory serves, “runas=currentuser” doesn’t immediately work. It needs something like runas={name of current user}. Even then, you get into context issues about the shell; some installers are picker than others.
I wound up doing…
wait sudo -i -u {name of current user as string} /path/to/command
…as the interactive shell gets more consistent results.
Note, however, that a the current user may not be an admin, and may not have installation privileges to /. For that reason I do…
I’ll assume you mean like the below so runas={name of current user} ?
If I use wait sudo -i -u {name of current user as string} /path/to/command are you saying I have to input each user name which will not be practical as this will be going to hundreds of users. Where exactly do I place wait sudo -i -u {name of current user as string} /path/to/command ?
The issues I see here are issues related to doing the “right” thing on the endpoint OS. For macOS, you have to remember the operations all translate out to running inside a bash shell – so it’s strings and character escaping/quoting all the way down.
First, the {current user} inspector returns a user object. On Windows it seems to implicitly return the username in some cases, but I have not found this to be the case on macOS. I’ve had to explicitly invoke {name of current user as string}.
Second, the user context under which the command is run. Since you’re installing software, do you intend the software to only be available to that individual user, or all users? If all users, running the macOS installer as {current user} will be problematic if that user is not an admin user (per macOS). If that individual user is intended, beware not all applications’ installers will correctly install into the user domain (e.g. ~/Applications). For these reasons, I think installing within the {current user} context may be problematic. As the BigFix agent runs as root, the installer will by default target the computer domain (e.g. /Applications).
Third, there is the issue of the shell environment in which the installer executes. In most cases BigFix’s implicit shell is adequate, but sometimes it’s not. I’ve often found on macOS that things “just work better” if I explicitly invoke an interactive shell. This can be because of file paths, the installer’s expectations, etc.
Ergo, I wager this will prove problematic for a number of reasons:
Instead, I suggest running the installer inside an interactive sudo shell as root, with explicit paths to the installer binary, and quoting to make sure paths with spaces are handled correctly.
