Postflight install script issue

[bluebox]

Problem: two different postflight script results between 10.5 and 10.6 IDMG installs. I think it might be the lack of the chroot jail on 10.6 not keeping the shell pointing into the sandbox, but here’s the problem/question anyway.

I have a launch daemon (plist file) installing into /Library/LaunchDaemons, and the script that it calls into /Library/Scripts. I was initially trying to make the daemon script file invisible (for various reasons), first by dotting the file (i.e. loading /.script.sh doesn’t work in PackageMaker), then by using SetFile from the Xcode developer’s tools to set the invisible bit [i]before [/i]packaging (didn’t work), then packaging SetFile with postflight script to execute after installation.

So: made a package with PM (whatever version Xcode tools for 10.5 comes with), including all three items. Added a postflight shell script (in SetFile’s scripts tab) that simply calls SetFile to set the invisibility bit on the daemon script, then deletes the SetFile executable.

Postflight script:[code]#!/bin/sh
/private/tmp/SetFile -a V /Library/Scripts/script.sh
rm /private/tmp/SetFile
[/code]This works using the following:

Host OS: 10.5
Install image: 10.5
BaseUpdates: 10.5.8 combo update
IDMG: 1.6b1svn246 (also works w/1.5rc1)

However, when I duplicate the above process under everything for 10.6 (host OS, install OS, PM for 10.6, IDMG 1.6b1), the installer places all three items properly into the image but fails on the postflight script, claiming the “no such file or directory” rant. (Not currently at my build computers, so I can’t paste the logfile – sorry). I tried using the package made under 10.5, but had the same result. I tried installing SetFile into /private/tmp, /private/var, /Library/Scripts, to no avail.

I don’t [i]have [/i]to have an invisible daemon script, but this brings up lot of other similar post-install script operations I will want to do in the future. I’m planning on supporting Snow Leopard only if possible (this is for Intel Macs only – 10.5 not necessary). I can’t exactly customize the OS with script operations if they’d all fail like this, so am I missing something obvious here? Anything else I can try?

BTW, huge thanks for this project! I wouldn’t even be attempting what I’m trying if not for IDMG.

Doug

[larkost]

First off the reason you are running into this problem is that on 10.6 I am disabling the chroot jail because it was killing the process. I have a very good idea of what is going on now, and durring Macworld had an odd thought about how to fix it, but need to put in some time testing it, but I am working on another InstaDMG project at the moment (maybe that one will be out this weekend). So for 10.6 your command winds up getting run against your boot volume.

While this sort of thing is why I put in the chroot jail in the first place, I do consider this sort of thing bad scripting on the package maker’s part. But the solution is really easy: you just have to reference the “target” drive that the installer is feeding you as the “$3” (third) argument to your script.

And you are also being a bit creative with the SetFile command, and there is a better way: include SetFile in the resources of your package, then reference it using the “$2” argument provided to your script. With this setup you don’t have to take care of deleting anything (something I am always scared of doing), and you don’t have to play weird games with the chroot environment: it will always be where you expect it to be.

So here is your modified script (assuming that you put SetFile in resources):
[code]#!/bin/sh
“$2/Contents/Resources/SetFile” -a V “$3/Library/Scripts/script.sh”[/code]

Note that I am quoting both paths in case they have spaces in them. This is also off-the-cuff and untested, so you might need to do some troubleshooting.

Overall I would say that you probably should not be trying to hide this. Smart users are going to find it anyways, and not-so-smart users are probably not going to be looking in /Library/Scripts in the first place. If you are hiding things in this script, then there is probably a better way.

[bluebox]

[QUOTE][u]Quote by: larkost[/u] [i]While this sort of thing is why I put in the chroot jail in the first place, I do consider this sort of thing bad scripting on the package maker’s part. But the solution is really easy: you just have to reference the “target” drive that the installer is feeding you as the “$3” (third) argument to your script.[/i][/QUOTE]
Ah, but I’m a bad bash-scripting newbie, and [lightbulb goes on] didn’t catch the connection of using special variables in the postflight script!

[QUOTE][u]Quote by: larkost[/u] [i]And you are also being a bit creative with the SetFile command, and there is a better way: include SetFile in the resources of your package, then reference it using the “$2” argument provided to your script.[/i][/QUOTE]
I [i]was[/i] including it as a package resource; the postflight script wasn’t finding the executable until…

[QUOTE][u]Quote by: larkost[/u] [i]So here is your modified script (assuming that you put SetFile in resources):
#!/bin/sh
“$2/Contents/Resources/SetFile” -a V “$3/Library/Scripts/script.sh”
Note that I am quoting both paths in case they have spaces in them. This is also off-the-cuff and untested, so you might need to do some troubleshooting.[/i][/QUOTE]
[b]…and it worked like a charm.[/b]

[QUOTE][u]Quote by: larkost[/u] [i]Overall I would say that you probably should not be trying to hide this. Smart users are going to find it anyways, and not-so-smart users are probably not going to be looking in /Library/Scripts in the first place. If you are hiding things in this script, then there is probably a better way.[/i][/QUOTE]
Totally right — I was appeasing others. Intended users of this image will not be allowed access to the system folder anyway.

Thanks!

[Author]

Posts