screen lock + policy run on first boot

What are you trying to achieve with Munki? Perhaps your workflow can be adjusted so that everything is done in Casper?

When I need to roll out large packages or when I am installing a package post image I have a policy to first cache the package then install it later.
As long as your package isn't needed by the end user immediately I've found that they can wait the short time it takes to cache and install the package.
In the case where it is needed straight away you'll find you'll save a lot of heartache and time by just incorporating it into your image and waiting the extra time to image the device.

I hope that gives you some ideas.

i'm not using munki (yet) in my current job but have used it everywhere else since its release.

what i'm trying to do here is replicate as closely as possible munki's "install at loginwindow" behavior as part of a modular imaging workflow.

the process is something like this:

netboot to a set with casper imaging

run configuration that includes just base image

base image is just OS with all current updates (baked with instadmg) and maybe some additional tools needed for first boot

post-imaging, machine reboots, and policy takes over to install apps, config, etc.

ideally, the screen is locked and provides some feedback to indicate what's happening

machine updates inventory, reboots, and is ready for use

since by default, casper provides no easy/workable solution for installing at the loginwindow (needed because there are no local or directory accounts present yet), i'd like to lock the screen to provide some feedback here. otherwise, someone may try to shut down/reboot/login or otherwise abort the installs under the hood.

in all cases, munki provides better feedback and is clearly doing something during an install run. for casper, i need to do a lot of work to get similar results. if i'm wrong, please correct me.

i'm not talking about caching packages for later installs, though the same applies to any install scenario, in my mind. munki handles all installs/updates pretty much the same way. i'm looking for consistent behavior here that doesn't involve a lot of work on my part to maintain.

while it's true that compiling in all the apps/config would avoid most or all of this issue, it's also less flexible. i don't want to have to compile multiple configs for slightly varying deploy scenarios. my goal is to use the same base image for everyone, then layer on various configuration as needed. since the config stage isn't baked into the image, it's way easier to change it at any time.

so, with that all said, is anyone approaching this problem in a sane way?

If you set your packages to install at reboot then Casper will handle restarting the Mac after applying your base image and locking the screen while these packages are getting installed.

The most notable scenario is when you want to install most any Adobe product. Those cannot be installed when booted from a non-system disk and must be installed while booted to their host OS. At this point, if you've added an admin account to your configuration then that account already exists.

We are using two special policy triggers: "INST FirstRun after Imaging" and "INST FirstRun after QuickAdd". Those are triggered for two different scenarios:

- on an freshly imaged computer: by a custom "at reboot" script in the image configuration. Basically it does stop the every15 launchd and then calls jamf -trigger "INST FirstRun after Imaging". Advantage: the screen is fully blocked by the default "we are installing software" message from Casper.

- on a freshly unpacked computer which just has an admin user created by filling out the welcome assistant. We then manually install a customized quickadd package, which triggers the "INST FirstRun after QuickAdd" policy in a postflight script. Advantage: The QuickAdd installer does not finish until the first run trigger has finished, so there is at least some visual feedback.

Both policies in turn trigger "INST FirstRun after Imaging and QuickAdd" so the setup is pretty modular, and you have two paths (monolithic imaging and "thin imaging") leading to a quite similar result. Not too elegant, but helps keeping my sanity.

However this setup does not work with SMB Distribution Points, as they casper will run into mount errors when running nested policies.

We had a discussion on the list, or here on JAMF Nation, a few months back about this. We've actually had a couple of discussions about it. jamfHelper will not lock the screen unless someone is logged in, and iHook won't work either I believe.

The ultimate solution, and I don't remember who had it (I tried to find the original chain), was to simply unload loginwindow so people could not login, and then re-load it, or restart the machine, when you are done with the install. Of course there is no status being displayed, so if a user walked up to a machine with no loginwindow, they might force a restart. But it is a start.

Steve

Hey Nate,

I am on my lunch break so I don't have much time, but if you drop me an email at tom.larkin@jamfsoftware.com I have a few solutions you can try to accomplish this. Then you could test them out and see which one fits your needs best and then post on the list so the community can see how it fares. I will try to get back to you this evening.

Thanks,
Tom

Id be interested in seeing some of the proposed solutions as well. I need to come up with one way of doing it and stick to it.

I'd say to let Casper do the heavy lifting by marking packages to install on first boot at imaging time. Casper will lock the screen at the login window with a "we are finishing up" type message and then reboot at the end. You could also create a policy that installs all necessary packages, and include a script that runs on reboot and is part of your Casper Imaging workflow that runs jamfhelper immediately to do a full screen window (fs) and then manually triggers the policy to install all necessary packages.

If any packages require a reboot, your work is done. If not, make sure to kill jamfhelper at the end of the script.

The script idea is nice since you can customize the messages and icons that jamfhelper shows to the end user.

Nate didn't have time to email me today and I just ended my work day so I can write up a quick idea on how to do this. However, since everyone's environment is different and may have different requirements I would recommend you all test this on your own and post your results.

Here it is in a nutshell:

1) create a blank PKG file in Composer. If you by chance capture any folders/files just delete everything

2) click the arrow to expand the PKG contents. Right click on the scripts folder, then select add bash script, then select add post flight script.

3) In the post flight script, you can use manual trigger policies to install any software, do directory bindings, and everything else a policy can do. Just know that not every software package can be installed via a manual trigger policy. So, test this out. Once done create the PKG file.

example:

/usr/sbin/jamf policy -trigger install_office2k11

4) Drop the PKG file once done with all the manual trigger policies you want to run into Casper Admin.

5) In Casper Admin if you double click (or get info) on your new PKG file and go to the options tab, there is a box that is labeled, "This Package Must be installed to the boot volume at imaging time." Check that box, then add to your imaging work flow.

JAMFHelper should then after imaging is complete run that PKG file, and it will run all your manual trigger policies with the screen locked. We tested this method this morning before we started working.

Let me if this works for anyone.

#Edited because Lion auto correct hates me...

thanks, tom. that's basically what i had already and tested again today. it's better than nothing but still not as informative as munki's behavior.

for now, using a payloadless package with postflight to run jamf policies is probably the best option.

it's still more to maintain. i roll my pkgs with luggage makefiles, so it takes two seconds to do. this type of workflow requires something like this pkg postflight. it would be better not to have to write more processes to handle installing software, considering it's one of casper's core features.

Nate,

I am not too familiar with all the ins and outs of Munki, but I have used it barely in the past. If this is something you would really like to see in Casper, maybe put in a feature request on JAMF Nation here and it can be reviewed.

If you have any more specific questions with these types of work flows feel free to drop me a line anytime.

Thanks,
Tom

Hi Tom,

i have submitted a feature request which seems to encompass the requirements in this thread: <https://jamfnation.jamfsoftware.com/featureRequest.html?id=269>

Incorporating or adapting munki's methodology into Casper would be really beneficial to many users. It might not be simple or done fast, but it would solve a lot of the common headaches we encounter.

Thanks,
Christoph

thanks, cristoph. i'm still a bit torn about adding feature requests like this. that may sound silly.

on one hand, i do believe casper should and could do some things differently and/or better. there's definitely a lot of room for improvement. as a general rule, i firmly believe we should always question our assumptions and keep iterating, improving.

on the other hand, there's a lot under casper's hood that should be cleaned up as well. adding functionality to the pile may be helpful in the short term but also has a tendency to increase technical debt (see http://en.wikipedia.org/wiki/Technical_debt).

these concerns are a bit off topic here and probably more appropriate at a user conference, though.

Hey Nate,

I just finished putting something similar together. I have a launchd job that watches a path and calls jamfHelper, then a pair of scripts to touch a file in the watched directory and then to clear the directory and kill jamfHelper. Once installed, I can set up startup policies to run the first script, install updates or whatever, then run the second script.

A bit hacky, but it works.

Jay

Edit: My launchd job:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>Label</key>
    <string>org.yourorg.loginwindow.banner</string>
    <key>LimitLoadToSessionType</key>
    <string>LoginWindow</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper</string>
        <string>-windowType</string>
        <string>fs</string>
        <string>-title</string>
        <string>Updating</string>
        <string>-description</string>
        <string>This Mac is being updated. Do not interrupt or power off.</string>
        <string>-icon</string>
        <string>/System/Library/CoreServices/Software Update.app/Contents/Resources/Software Update.icns</string>
    </array>
    <key>QueueDirectories</key>
    <array>
        <string>/var/lockloginwindow</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
    <key>WatchPaths</key>
    <array/>
</dict>
</plist>

Stick it in /Library/LaunchAgents/

jay, you da man.

i'll check it next time i get a chance. we need to catch up sometime.

You can lock the screen at the login window using this command.

open /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app

In SL you can see the login window but can't do anything, in Lion you just see the Lock icon. (You might be able to display a message at this point or you could customize Apple's LockScreen image if necessary). Kill it with killAll LockScreen or just reboot.