You may be able to disable SIP via a package, rather than having to boot into Recovery. Not 100% sure you can disable it, but @rtrouton documented a method to use csrutil to add NetBoot servers via package:
Of course, I have to ask the question about why exactly you want to disable SIP, and to remind you that, at some point in time, in a future major OS revision, you may not be able to disable it (much like 10the ability to boot an OS in 32-bit mode was removed). So I would not view this change as anything other than a temporary workaround.
I'm under the impression you can mess around with the SIP protected areas if you boot from another disk so I would just make the change during imaging, before rebooting to the Macintosh HD.
I haven't tried a config profile to see if it overrides dockfixup completely. We use forced config profiles on our school lab deployments.
In most other cases (one to one edu deployments and business deployments) we try to leave the dock to the user.
We're trying to stick with SIP enabled if possible though. Switching it off feels a bit like leaving out the recovery partition when 10.7 first appeared. I'm sure we're going to find out there's some kind of horrible knock-on effect when you disable it!
use dockutil with a login script like outset
do you want to enforce a dock on users? or just give them a base to work with then they can make changes themselves?
We also tend to let users have a bit of freedom. We give them a nice base to work with but after that first login they can add and change as they wish.
I'm not certain why you would want to manage a dock's contents using anything other than a configuration profile at this point. There's a great little web-based tool called Dock Master that will build such a profile for you.
You can choose to modify the resulting .mobileconfig file as you like (for example, I change the PayloadScope to User).
"I'm not certain why you would want to manage a dock's contents using anything other than a configuration profile at this point."
Because a dock managed via configuration profile is immutable. If you want to set a useful default starting Dock, but still allow users to customize it to their own needs, a configuration profile isn't helpful.
The writing is on the wall, if you have to disable SIP to do "something" ....
I would guess that from Apple's point of view you are doing that "something" wrong.
PS or you could look at this as an opportunity to stop managing setting that Apple doesn't want you to manage and focus on security settings.
"Sorry manager/user/boss/lame co-worker...... Apple new cutting edge security has removed our ability to manage the dock/sidebar/non-security setting of your choice"
PS or you could look at this as an opportunity to stop managing setting that Apple doesn't want you to manage and focus on security settings. "Sorry manager/user/boss/lame co-worker...... Apple new cutting edge security has removed our ability to manage the dock/sidebar/non-security setting of your choice"
I would love it if Apple would stop putting shit in my dock. I don't want/need iAnything in my dock, Maps are never needed IN THE DOCK, , and Keynote, Pages, etc can die in a fire.
Until Apple stops telling all users what they WANT, people will NEED to disable things.
OS vendors shouldn't be in the business of dictating a user's wants/needs.
You are right Drew.....
The issue is that with all non-security setting is that everyone wants something different, you hate the Apple apps and Bob, Alice love them and Dave wants his dock on the right side but doesn't even use it...
We have to stop trying to fight Apple defaults if we can...the soon we accept that the better, if you want to fight the Apple defaults open ticket with Apple and get other admins to do the same.. : )
@gregneagle - I'm not dictating anyone's needs or wants, just registering that a more "sane" default would be Finder, System Prefs, and maybe a browser. Adding 15 icons to the dock (and in some cases re-adding them after updates or adding new down the road) is a bit heavy-handed for a company that pretends to be about good user experience.
And for that matter, please allow me to delete Applications which have no purpose on my machine: Messages, iTunes, iBooks, Game Center, FaceTime, Quicktime Player...to name a few.
Contrary to the message from Apple, there is absolutely no reason they should be "required by OS X" and it just goes to show that it is not about letting users run their computers as they desire.
I can see both points of views here. As admins, generally speaking I feel we shouldn't be controlling an end user's Dock experience, other than perhaps setting up a sensible default with the most used apps for your environment during initial imaging. After that, my personal opinion is, its up to the user on how they want their Dock to look. Obvious exceptions would be things like a) a lab environment, or b) kiosk style Macs, wherein both cases you'd probably want to ensure a consistent Dock through reboots or even make it immutable.
But this is where I think Apple gets itself into trouble of sorts. Once I've set up my Dock the way I want, I don't feel they have the right or authority to be modifying it without my explicit consent. Hence the intense dislike of the dockfixup process by admins. Even the name dock"fixup" is extremely pretentious to me. As if my Dock needs to be "fixed" by Apple because it doesn't contain their default applications or stuff they've installed after I upgraded. No, my Dock wasn't broken thank you very much Apple. I set it up the way I wanted it actually. I know! Amazing concept!
The issue here is a concern I've had with Apple for years. Apple seems to cater to the lowest common denominator as far as technical skills. So, grandma/grandpa at home doesn't need to even understand what the Finder is, or how to locate any apps, Apple feels they just have to stuff all their apps into the Dock. Simplify (read: dumb down) the user experience as much as possible. Generally speaking, making things simple and intuitive is a good thing and its served Apple well. However, there are better UX ways of handling this situation. (Read below for one way I handle it) We've all likely seen how this practice has led to uninformed and sometimes even dumbed down users. I can't even remember the number of times I've had to deal with "my application is gone!" type support calls because somehow an app was removed from the Dock and the user simply doesn't even know they can find it in, you know, the main Applications folder, or even Spotlight. To some people who have been trained by Apple in this way, no app in the Dock = the app is gone and/or uninstalled.
The other issue is that the Dock tends to breed muscle memory and adding a bunch of Dock icons shifts other icons around, causing the user to need to adjust their muscle memory behavior, or go in and remove the newly added dock icons. No good UX if you ask me.
So in this regard I definitely understand the issue some have with Apple's dockfixup process. I don't have a problem with their default dock out of the box. After all, they can't meet everyone's needs here, so they set up a sensible default for a home user with OS X installed apps, but after the Mac has been set up and in use by someone, Apple really should keep their hands off it.
To put this another way, I understand how "individual" everyone's Dock use it that, I've put special scripts together that when an application is installed from Self Service, it checks to see if the app is in the Dock and pops up an "offer" to add it if its not there. If its an upgraded app that is already there in the Dock, it just exits. The user can simply click No or Cancel and leave their Dock as is. If they click the Add button in the dialog, I use dockutil to add it in, often adjacent to other related apps (Firefox after Safari if its in the Dock for example) I don't just shove the new application icon down on them whether they want it or not. I just don't think its a good user experience. I only wish Apple thought the same.
@barnesaw It's not about "dictating a user's wants/need". The dock is as much a marketing surface as it is an application launcher. If you don't want them on the dock, fine; but what good does it do to add some new (hopefully awesome) application to the system, and then not advertise its availability by leaving it off the most visible user-interaction surface on the system?
Just remember that there are legitimate reasons for manipulating the dock post-upgrade, whether those reasons apply to you or not.
@mikeh - If Apple modifies my dock, it is about them dictating my wants/needs, because I had the dock I wanted and needed. I already have a dock, they don't need to market to me.
You know what else IS dictating wants/needs? You can't tell me this screenshot makes any sense whatsoever. Stop wasting space with this, and all the other crap I have no use for but apparently can't delete...
Anyone know if there is a way to track whether 'dockfixup' has been run?
I wanted to figure out if there is an easy way to make sure my dock 'tweaking' script waits for that process to finish before mine makes modifications. (either a plist or a process that can be watched or a plist value that is changed would probably work)
Chess.app (and all other default applications installed with the OS) are specifically listed as protected by SIP in the
I would agree it seems very silly for Apple to put up the SIP wall on something as innocuous and useless as Chess.app. The only possible reason I can think of for doing this is, Apple is worried a piece of malware could remove and add a new compromised version of Chess.app, or any other default OS X application on a Mac, and when its run by the user does something nefarious. Seems a bit spy vs spy like to me, but that's really the only reason I can come up with for being that stringent in what it protects.
FWIW, if you boot the Mac to another boot volume, even a 10.10.x OS, you can easily delete Chess.app or any other default app and then reboot back into El Capitan and the OS won't miss it at all. In fact, Arstechnica did just that in their full review of El Capitan.
Ah, I think i figured it out.......
There is a key in
called mod-count. It's an integer that seems to be incremented every time the dock is modified. It looks to me like the initial value is 1, then dockfixup runs, and it increments to 2....
so, theoretically, i could make a while loop that waits for the mod-count to go up to 2, then trigger my own 'fixup' script to run.
so what is the deal? did anyone figure out how to clean up the dock? I do agree with @barnesaw . Apple should let us manage the dock and customize as we see fit for our environment. Enterprise MAC admins create user experiences. I for one, Like to deploy a custom dock with applications my users need and not what apple thinks they need/want.
I am testing the dockfix during imaging, and not post as I had it originally in Yosemite. I will post results if any different.
To solve this in our environment I split my first boot script up into two. One that runs "At Reboot" and one that runs "After" (This is where you need to put the commands I reference). Since the Mac that is imaging is booted to the Netboot image SIP protected areas can still be modified. To keep dockfixup from adding icons back I use the following command. This has been working great so far...
defaults delete /Volumes/Macintosh HD/System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup add-app defaults delete /Volumes/Macintosh HD/System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup add-doc
@koszyczj that's very ingenous, thank you for that one. Love it.
By the way, can you tell me how your script knows it is "after" Casper has done all of its work and this is a subsequent boot? My post-install script is called at system startup but seems to be running while Casper is "finishing installing" which is most annoying, because Casper does a hard reboot before my script is finished, leaving software not fully installed. In fact I've basically given up trying to script this and instead call my script manually via ARD's UNIX command after Casper is done. Sorry if this question is off topic, folks.
@endor-moon I just set the script to run "After" or "At Reboot" in Casper Admin. I could be completely wrong but my understanding is that with the script set to run After it will apply my 10.11.1 DMG, then execute the script, then all of my other dmg's and scripts are copied and run during the first boot. When the script is set to run After it should show up under "Macintosh HD" and not "Prepare First Run Script". I hope that helps.
@koszyczj So, do you mean that you did the first command as one script, that runs "After," and the second command as another script that runs "At Reboot?"
I have a similar two-line script for Yosemite that works like a charm, but I am having some issues with El Capitan. I have it set to run "At Reboot." Maybe I can use my script, but just have it run "After" the Base Image install as in your example?
#!/bin/sh /usr/libexec/PlistBuddy -c "delete:add-app" /System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup.plist /usr/libexec/PlistBuddy -c "delete:add-doc" /System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup.plist exit 0
i use this script set to run "After" the Base Image install which is similar to @itupshot
that works for me.
#!/bin/sh /usr/bin/defaults delete "$1/System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup" add-app /usr/bin/defaults delete "$1/System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup" add-doc exit 0
I just also realized that because I have to run it "After" the base image, I have to define which volume to run the script on. As in @koszyczj's example:
defaults delete /Volumes/Macintosh HD/System/...
I'll edit mine accordingly for El Capitan, and see if that works for me.
For anyone else looking into this while creating a fresh image, I found a solution.
I booted into recovery, disabled SIP in the Terminal
Ran the following in the command:
/usr/libexec/PlistBuddy -c "delete:add-app" /System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup.plist /usr/libexec/PlistBuddy -c "delete:add-doc" /System/Library/CoreServices/Dock.app/Contents/Resources/com.apple.dockfixup.plist
Enabled SIP and reboot:
csrutil enable reboot
Following this I created a custom User Template with the preferred Dock and tested it with an AD login - the Dock populates fine using the template and no Apple apps are added.
Hopefully we see a better solution for this soon.