Bypassing Setup Assistant

[Shawn]

Hello,

We are in the process of testing upgrading to Mavericks using the CreateOSXInstallPackage utility for the first time. I have created a .pkg to append to it to touch the .AppleSetupDone file to pass the setup assistant prior to the login window. This works, however after a user logs in (first time or not) they are prompted for with the setup window for the same information that you would get during a typical mavericks setup. 

Does any have a package or script to work around this. It is the only thing preventing us from deploying it (aside from iLife) using munki. We want users just to be able to login and not notice a thing as far a these setup assistants go.

Shawn Knight

Systems Administrator

Central Michigan University

[Erik]

This isn't proper munki group discussion, however this should put you in the right direction. Rich Trouton created a script.

http://derflounder.wordpress.com/2013/10/27/disabling-the-icloud-sign-in-pop-up-message-on-lion-and-later/

[Graham Gilbert]

You can also use a profile / MCX (see http://managingosx.wordpress.com/2012/07/26/mountain-lion-suppress-apple-id-icloud-prompt/)

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Anthony Hunt]

It was strange that this came up as I was just thinking about it when I read it yesterday.  I have tried building a custom package today; with the linked script in a package. 

From this URL:

http://derflounder.wordpress.com/2013/10/27/disabling-the-icloud-sign-in-pop-up-message-on-lion-and-later/

I have tested the package manually and it appears to work when deployed via Remote Desktop.  It seams not to be deploying when used with createOSXinstallPkg:

sudo ./createOSXinstallPkg --source /path/to/Install\ Mac\ OS\ X\ Lion.app --pkg /path/to/DisableSetupAssistant.pkg

Anyone else having this issue? 

[Gregory Neagle]

That script was not written to run properly anywhere other than the current boot disk. That rules out it working properly with createOSXinstallPkg -- I am assuming you stuffed it into a payload-free package?

-Greg

 

[Anthony Hunt]

Ahhh... That'll probably be why then!  Yes I did build a payload free package.  I presumed that the package would be run post deploy?  

[Gregory Neagle]

On Oct 29, 2013, at 2:06 PM, Anthony Hunt <ant....@gmail.com> wrote:

> Ahhh... That'll probably be why then! Yes I did build a payload free package. I presumed that the package would be run post deploy?

No. The packages are installed at the same time as the OS.

Perhaps you can make use of this if you really want to use that script as-is: http://derflounder.wordpress.com/2013/05/13/first-boot-package-install-pkg/

-Greg

[Anthony Hunt]

I'm not too worried about this script, it was just a means to an end. 
I searched the group for a little while and considered that this was 
one of the afor mentioned methods. 

Any advice greatly appreciated. 

Anthony.

[Timothy Sutton]

My own preference for disabling the iCloud setup assistant has been to use a profile, like Greg already pointed out here (substituting ’10.9' for LastSeenCloudProductVersion):

http://managingosx.wordpress.com/2012/07/26/mountain-lion-suppress-apple-id-icloud-prompt

…and making a package that places this profile in /private/var/db/ConfigurationProfiles/Setup. When OS X boots, it looks for profiles in here and installs them automatically.

This way, I can have a single package that works for multiple scenarios, ie. for baking into a non-booted base image or for workflows like DeployStudio and OS X packages built with createOSXInstallPkg.


-Tim

[Gregory Neagle]

On Oct 30, 2013, at 10:30 AM, Timothy Sutton <t...@synthist.net> wrote:

> My own preference for disabling the iCloud setup assistant has been to use a profile, like Greg already pointed out here (substituting ’10.9' for LastSeenCloudProductVersion):
>
> http://managingosx.wordpress.com/2012/07/26/mountain-lion-suppress-apple-id-icloud-prompt
>
> …and making a package that places this profile in /private/var/db/ConfigurationProfiles/Setup. When OS X boots, it looks for profiles in here and installs them automatically.

There are some caveats here, though:

1) You might want not to have to wait until a reboot to install profiles, and
2) Don't you have to pay attention to .profilesAreInstalled and .profileSetupDone ?

To avoid these issues, I create a package that "installs" the profile to a management folder and then uses /usr/bin/profiles -I -F /path/to/some.mobileconfig to install it. This only works for the current boot volume, however -- so it works well with Munki, and not at all with AutoDMG and Deploy Studio and createOSXInstallPkg.

-Greg

[Timothy Sutton]

On Oct 30, 2013, at 1:39 PM, Gregory Neagle <gregn...@mac.com> wrote:

> There are some caveats here, though:
>
> 1) You might want not to have to wait until a reboot to install profiles, and

Right. In this case, I’m always using the profile to handle either an upgrade to 10.9 via createOSXInstallPkg, making it part of an image that will boot for the first time or running it as part of a DS Netboot workflow that’s going to then boot the system.

> 2) Don't you have to pay attention to .profilesAreInstalled and .profileSetupDone ?

Yes. One would need also add a postinstall script to remove those files if they’re present.


-Tim

[Gregory Neagle]

On Oct 30, 2013, at 12:05 PM, Timothy Sutton <t...@synthist.net> wrote:

> On Oct 30, 2013, at 1:39 PM, Gregory Neagle <gregn...@mac.com> wrote:
>
>> There are some caveats here, though:
>>
>> 1) You might want not to have to wait until a reboot to install profiles, and
>
> Right. In this case, I’m always using the profile to handle either an upgrade to 10.9 via createOSXInstallPkg, making it part of an image that will boot for the first time or running it as part of a DS Netboot workflow that’s going to then boot the system.

My problem is I never get these things perfectly right the first time and often have to deploy new profiles/software/scripts/tools later. So I don't like solutions that work only at first boot or at "imaging" time.

I prefer solutions that allow you to correct your mistakes later, because I always make mistakes!

-Greg

[Timothy Sutton]

Indeed.

A compromise (but that also requires more work in a postinstall) might be, if the installation target volume is the booted one, run profiles -I -F immediately on the config profile in /var/db/etc.. and then delete it. If the target volume is not the booted one, then clear out those dotfiles so that it instead just gets installed on the next boot.

Either way, it definitely adds more complexity to make one package to work in multiple scenarios.


-Tim

[Anthony Hunt]

Hi All,

I feel I lit the blue touch paper.... then missed the firework... let alone the fuse!!

Firstly, thanks for all of the feedback. It's very much appreciated.

I think i failed to communicate the circumstance in which I was using this.  Which was going to be to upgrade machines that are currently deployed, rather than delta updating a fresh 10.8 install. So in that vein, an updater that runs on first boot seemed the most logical method.  

Now, in fear of starting a flame war, I feel it bad practice to install system packages to any other system drive other than the one currently booted.  Hence why the first boot option works for me.  My main arguementn for doing it this way is regardless of how the developer has written their installer it will always be written to the right system.  Years gone by with bad installer practices and temp files and everything else has taught me this.

In terms of getting right first time... I too suffer from this infernal problem, and spend lots of hour moping up things that should have been done differently if we'd have sat down and talked everything through properly to start with.  And then fixing my own bad mistakes which we won't talk about!!!

To sum up,  thanks again for all of your feedback.  It has been very much appreciated.  I already have the necessary in our OD to make the profiles ignore the iCloud setup, but will be fixing up our local deployments with the first boot script.

Thank you ALL!!

Anthony.

[David Iwanicki]

Greg,

Any suggestions on good places to "hide" the management folder for .mobileconfig files as you suggest below?

I am trying to find the best way to let Munki know if Profiles are installed. Seems the "installs" key would be better than just relying on "receipts". I'm working with Graham Gilbert's tool: https://github.com/grahamgilbert/Profile-Manager-Enrollment, for a point of reference. It uses /tmp, which is not a good place to look for "installs" items, I'm thinking.

I know this thread is a little old, but it is closest to what I'm trying to figure out.

Thanks!

David

[Gregory Neagle]

Why do you need to "hide" them?

An 'installs' key is not of much use; the fact that there is a .mobileconfig file on disk doesn't tell you if it's been installed.

If you want to keep a copy of a profile around, install the .mobileconfig  to a directory like /Library/YourOrgName/Profiles

But again, having a copy on the local disk doesn't tell you if the profile has been installed (via /usr/bin/profiles) or not.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[bryanzak]

Our approach to managing profiles with Munki is to package them into an installer package and let Munki use receipts to decide if the profile has to be installed or not.

I know it's a bit cumbersome but I just tossed up an example as a gist real quick:

https://gist.github.com/bryanzak/9655953

It takes a plist and has a create_profile.sh script to make the profile. There is a create_package.sh script that takes the profile and makes an installer package (which installs the profile in /tmp and uses a postinstall script to install)

This works very well for us. Any time we need to change the profile, we just increment the package version number and import into Munki and all of our clients get the updated profile.

Bryan