https://www.macobserver.com/tips/quick-tip/how-to-change-mojave-default-screenshot-location/
Set default homepage – Safari OSX
21 AugIf you change the defaults on com.apple.Safari in English.lproj, the settings will be migrated into new user accounts. At least it worked for me.
sudo defaults write /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.Safari AlwaysRestoreSessionAtLaunch -bool false
sudo defaults write /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.Safari NewWindowBehavior -integer 0
sudo defaults write /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.Safari HomePage -string “http://www.yoursite.com/”
I was copying the com.apple.Safari.plist from my admin account to the “/System/Library/User Template/English.lproj/Library/Preferences”, and that didn’t work because the keys above were gone… already migrated to whatever secret location Apple has moved them to. Adding them manually into the plist appears to work.
Original content/thread – https://www.jamf.com/jamf-nation/discussions/19668/homepage-in-safari-9-on-el-capitan
Munki Setup
22 AprIf you haven’t yet used Munki its an excellent open source tool for software/profile deployment
Below is quick guide on how to get up and running on Yosemite Server, full credit to the awesome Github community and OSXDominion along with my own notes đ
Setting Up Munki With OS X Yosemite Server
There are many ways to set up Munki, since itâs just a webserver. TheDemonstration Setup is a great way to get started, but doesnât list the steps for setting up OS X Server. A lot of new Munki admins (or generally new Munki admins) may have an OS X Server they have access to, but not other web servers, so a guide to getting started with the latest version of OS X Server (as of writing time, thatâs Server 4, on Mac OS 10.10.2 Yosemite) may be helpful.
This is all assuming youâve got Server.app set up and running.
If the Websites service in Server.app is running, turn it off first.
The first steps are to create the Munki repo in the location that Server 4 uses to store website data:
mkdir /Library/Server/Web/Data/Sites/Default/repo
mkdir /Library/Server/Web/Data/Sites/Default/repo/catalogs
mkdir /Library/Server/Web/Data/Sites/Default/repo/pkgs
mkdir /Library/Server/Web/Data/Sites/Default/repo/pkgsinfo
mkdir /Library/Server/Web/Data/Sites/Default/repo/manifests
Change permissions to make sure itâs accessible:
chmod -R a+rX /Library/Server/Web/Data/Sites/Default/repo
In the Server.app Websites pane, edit the âServer Websiteâ (port 80) settings:
Next to âRedirectsâ, click âEditâŚâ, and remove the only redirect (which automatically redirects port 80 to port 443 traffic). It should look like this:
Next, click âEdit Advanced Settingsâ and check the box for âAllow folder listingâ (just for now â itâs easier to visually test this way):
Turn the Websites service on.
Open up Safari, navigate to:
http://localhost/repo/
You should see a page like this:
If you can get to this point, youâve done the website setup work. Now you can go to the next section:
https://github.com/munki/munki/wiki/Demonstration-Setup#populating-the-repo
Once youâve populated the repo, you can set up a new manifest called âtest_munki_clientâ. Follow the instructions exactly:
https://github.com/munki/munki/wiki/Demonstration-Setup#creating-a-client-manifest
Go through the Client Configuration section:
https://github.com/munki/munki/wiki/Demonstration-Setup#munki-client-configuration
Here, you need to do two things on your OS X client.
If you are testing this on the OS X Server itself (i.e. you are only using one machine total), do this:
sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://localhost/repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"
If you are testing Munki on a different client machine from the server, do this:
sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://ip_or_domain_name_of_server/repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"
And then finally you can check to see if Munki behaves as youâd expect:
sudo /usr/local/munki/managedsoftwareupdate -vv
Populating the repo
We now have a working Munki repo â but itâs completely empty and not useful at all. So letâs start to populate the repo.
Weâre going to use some tools distributed with munki to import packages into our new Munki repo. Download the current munki installation package at https://github.com/munki/munki/releases/latest.
Install the Munki tools by mounting the disk image and double-clicking the Installer package and installing like any other package. A restart is required after installation.
The tools youâll use as an administrator are available from the command-line, and are installed in /usr/local/munki. This location is not in the standard search path, so youâll need to either add this directory to your search paths, or be sure to type the full path when invoking these tools.
The tool we will use to import packages into the munki repo is called munkiimport. We need to configure it before we can use it â telling it where to find our repo, among other things.
bash-3.2$ /usr/local/munki/munkiimport –configure
Path to munki repo (example: /Volumes/repo): /Users/Shared/munki_repo
Repo fileshare URL (example: afp://munki.example.com/repo):
pkginfo extension (Example: .plist):
pkginfo editor (examples: /usr/bin/vi or TextMate.app): TextMate.app
Default catalog to use (example: testing): testing
We are first asked for the path to the Munki repo, and since we set one up at /Users/Shared/munki_repo, thatâs what we enter.
Next, we are asked for a repo fileshare URL. This is used when the repo is hosted on a remote file server, and this would typically be an afp:// or smb:// URL specifying the share. Since weâre hosting the repo on the local machine, weâll leave this blank.
We are then asked to specify an extension to append to the name of pkginfo files. Some admins prefer â.plistâ, some prefer â.pkginfoâ. Personally, I just leave it blank â Munki doesnât care.
Next, you are asked for an editor to use for the pkginfo files. If you like command-line editors, you can specify /usr/bin/vi or /usr/bin/emacs for example. If you, like me, prefer GUI text editors, you can specify a GUI text editor application by name (but be sure to include the â.appâ extension). I picked TextMate.app, but you could choose TextWrangler.app, BBEdit.app, or even TextEdit.app.
Finally, you are asked for the default catalog new packages/pkginfo should be added to. We’ll use a “testing” catalog for this.
Further reading here
Microsoft Remote Desktop – Question Mark OSX
21 MarIf you are on El Captian and have updated to the March 18 2016 Microsoft RDP update you will notice the dock icon you probably have will no longer work.
Some muppet at Microsoft has renamed the app to “microsoftremotedeskop” without any spaces. Simply remove from dock, reopen from your application folder and all will be well…..
Force OSX to use SMB1
8 JanYou can force connections to default to SMB1 via an nsmb.conf file placed in /etc
sudo echo “[default]” >> /etc/nsmb.conf
sudo echo “smb_neg=smb1_only” >> /etc/nsmb.conf
How to Disable System Integrity Protection (rootless) in OS X El Capitan
4 DecApple has enabled a new default security oriented featured called System Integrity Protection, often called rootless, in OS X 10.11 onward. The rootless feature is aimed at preventing Mac OS X compromise by malicious code, whether intentionally or accidentally, and essentially what SIP does is lock down specific system level locations in the file system while simultaneously preventing certain processes from attaching to system-level processes.
While the System Integrity Protection security feature is effective and the vast majority of Mac users should leave rootless enabled, some advanced Mac users may find rootless to be overly protective. Thus, if youâre in the group of advanced Mac users who do not want SIP rootless enabled on their OS X installation, weâll show you how to turn this security feature off.
For those wondering, System Integrity Protection locks down the following system level directories in OS X:
/System
/sbin
/usr (with the exception of /usr/local subdirectory)
Accordingly, rootless may cause some apps, utilities, and scripts to not function at all, even with sudo privelege, root user enabled, or admin access.
Turning Off Rootless System Integrity Protection in OS X El Capitan 10.11 +
Again, the vast majority of Mac users should not disable rootless. Disabling rootless is aimed exclusively at advanced Mac users. Do so at your own risk, this is not specifically recommended.
- Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot OS X into Recovery Mode
- When the âOS X Utilitiesâ screen appears, pull down the âUtilitiesâ menu at the top of the screen instead, and choose âTerminalâ
- Type the following command into the terminal then hit return:
csrutil disable; reboot
- Youâll see a message saying that System Integrity Protection has been disabled and the Mac needs to restart for changes to take effect, and the Mac will then reboot itself automatically, just let it boot up as normal
You can also issue the command by itself without the automatic reboot like so:
csrutil disable
By the way, if youâre interested in disabling rootless, you may also want to disable Gatekeeper while youâre in the command line too.
If you plan on doing something else in the Terminal or OS X Utilities screen you may want to leave off the auto-reboot command at the end, and yes, in case you were wondering, this is the same recovery mode used to reinstall OS X with Internet Recovery.
Once the Mac boots up again, System Integrity Protection will be disabled entirely in OS X.
Checking the Status of Rootless / System Integrity Protection in OS X
If you want to know the status of rootless before rebooting or without rebooting the Mac into recovery mode, just issue the following command into the Terminal:
csrutil status
Youâll either see one of two messages, enabled indi:
$ csrutil status
System Integrity Protection status: enabled.
or
$ csrutil status
System Integrity Protection status: disabled
If at any time you wish to change the status of rootless, another reboot into Recovery Mode is required.
How to Re-Enable Rootless System Integrity Protection in OS X
Simply reboot the Mac again into Recovery Mode as directed above, but at the command line use the following syntax instead:
csrutil enable
Just as before, a reboot of the Mac is required for changes to take effect.
As previously stated, the vast majority of Mac users should leave rootless enabled and embrace System Integrity Protection, as most OS X users have no business in the system level directories anyway. Adjusting this feature is really aimed at advanced Mac users, whether IT, sysadmins, network administrators, developers, tinkerers, security operations, and other related highly technical fields.
Turn off Autocorrect – OSX
24 Nov- Open System Preferences (choose Apple > System Preferences).
- Choose Keyboards.
- Click the Text tab.
- Deselect the tick in Correct Spelling Automatically.
Fix unable to join Wi-Fi in OSX El Capitan
2 OctIf you find yourself unable to join ANY wifi network simple boot with option key held down, connect to your wifi (youll need to enter your key)….all should now be working