Category Archives: Uncategorized

Clean Up XML Formatting in BBEdit

If you work with XML or .plist files you’ve most likely run into a file that is proper XML but is not human readable due to its formatting.  That usually means running it thru an xml format cleanup process to make it human readable. If you work with those files in BBEdit like I do, there is a feature called Text Filters that allows scripts to be run on the file you’re working on.

Create a simple bash script and save it to ​~/Library/Application Support/BBEdit/Text Filters/plist_format.sh:

#!/bin/bash
plutil -convert xml1 -o - -- -

Now if you have a file open that has no line breaks or indentation like this:

<?xml version="1.0encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0">...

Access the script in BBEdit in Text->Apply Text Filter->plist_format and it will format the output in-app.

<?xml version="1.0encoding="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>distribution_style</key>
    <false/>
    <key>identifier</key>
    <string>com.github.munki.pkg.isIllustrator18Installed</string>
    <key>install_location</key>
    <array>
        <string>/</string>
    </array>
    <key>name</key>
    <string>isIllustrator18Installed-${version}.pkg</string>
    <key>ownership</key>
    <string>recommended</string>
    <key>postinstall_action</key>
    <string>none</string>
    <key>suppress_bundle_relocation</key>
    <true/>
    <key>version</key>
    <string>1.0</string>
</dict>
</plist>

 

Tagged , , , , , ,

Configuring System Integrity Protection in a NetBoot environment

System Integrity Protection (SIP) can be enabled and disabled using csrutil from OS X Recovery per Apple’s documentation.  However, booting to Recovery is a local-only procedure and allows no remote access capabilities. I work remotely so it interests me to have capabilities to remotely change SIP status instead of walking a user thru the Recovery process which is daunting over the phone. We currently have NetBoot with Apple Remote Desktop (ARD) access in all offices and that can be leveraged for our needs.

The NetBoot environment by default doesn’t allow for csrutil access to enable or disable SIP: original-netboot-no-csrutil-access.png

However, if we copy boot.efi from a Recovery partition and use it to replace the i386/booter file in the NetBoot NBI the NetBoot environment can adjust SIP’s status:adjusted-netboot-csrutil-access.png

To extract the boot.efi first we have to determine which partition the Recovery OS is on and mount it. In this example the Recovery OS is on /dev/disk1s3 and is on an APFS formatted disk.  Use mount -t apfs /dev/disk1s3 /path/to/mountpoint to mount it to a mount point and copy the boot.efi file off:mount-recoveryhd.pngNow copy the boot.efi in the NBI’s i386/ directory, name it booter and give it 664 root:admin permissions:copy-boot.efi-to-booter-in-NBI.png

Now when I NetBoot to that NBI I can gain access with ARD and adjust SIP status with csrutil.

Tagged , , , , , ,

Cache Active Directory credentials off-site

A scenario I ran into recently involved an existing user who had their computer re-imaged with OS 10.10.5.  Their user data was backed up and restored prior to returning the system to the user.  To restore data I first use createmobileaccount to create a home directory and cache user information based off of AD, then rsync the data into the local home directory.  Since I don’t know the user’s password I don’t use the -p option leaving the cached account information without a password. Instead, the password is cached the first time the user logs in.  However, that only works when the computer can talk to our AD environment.

This user didn’t log in prior to taking the laptop out of the office for the week (who does that after a computer upgrade?!).  Since no password was cached there was nothing to authorize their credentials against. This could make for a long week for this user.

Since I had already created a home folder with all the user data I didn’t want to erase it or even have to bother with moving it around to a temporary user account.  Instead I did the following to preserve the files and allow the user to log in off-site:

  1. Have the user log in as a local admin.
  2. Have the user log into our company VPN as themselves.
  3. I gained access to the computer via Apple Remote Desktop (ssh, ScreenSharing, or any other means would work as well)
  4. I removed the current cached user info, sans password with sudo dscl . -delete /Users/<username>. This removes the locally cached information for the user from /var/db/dslocal/nodes/Default/users/<username>.plist but leaves the /Users/<username> home folder data alone.
  5. I then issued sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n <username> -p <password> . I had the user type their password to match their AD account.

Step 5 recreates the cached user information in /var/db/dslocal/nodes/Default/users/<userid>.plist (as long as the computer can talk to Active Directory), but this time with a cached password. Log out of the admin account and now the user can log in as themselves off-site using their AD credentials and access the already created home directory in /Users/<username>.

Tagged , , , , , , , ,