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>

 

Advertisements
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 , , , , , , , ,