Hard Drive Space Issues

So, today I was looking through a dashboard which contains the results of reports from our managed Macintosh computers, and I came across a lab computer with 86% of it’s drive filled.

Curious, I went in and started to investigate the issue.

On our lab computers we remove user home directories if they are unused after 3-4 days to help preserve drive space. The worst case scenario is that up to 20,000 students can sit behind one of our lab computers. Now that’s a lot of home directories and a loads of data.

Long story short, I came across a folder:  /private/var/folders which was over two hundred gigabytes in size.

Turns out this folder holds user cached files and other such temp files. A web search turned up this post with some very interesting and useful information:

http://blog.magnusviri.com/what-is-var-folders.html

So now we are in the process of implementing some changes to our home directory removal tool by adding some code which will also remove the cache/temp data of that user.

Hopefully this will help to reduce disk usage.

So if you find that your Macintosh computer’s hard drive is missing a lot of free space, hopefully this post will help you in figuring out what is using up some of the space.

A word of caution. Remove cached/temp files at your own risk. A worst case scenario can result in a system that won’t boot.

Test, test, test, test, test, test…

Configuring iTunes from Command line.

Yesterday, with the help of Shaun Kepert, we solved a nagging iTunes issue.

We need to set the Sidebar in iTunes to always show on our SINC Site Macintosh computers, and we need to accomplish this through the command line since we have to script this.

Shaun finally figured out which preference file was being modified and more specifically what data needed to be modified.

So, here’s the process to change the setting. Make sure iTunes is not running:

1. Copy ~/Library/Preferences/com.apple.iTunes.plist somewhere else to work in it. I will probably put it in /private/tmp/

2. Use plutil to convert the com.apple.iTunes.plist to an xml file from it’s original binary file format.

/usr/bin/plutil -convert xml1 /private/tmp/com.apple.iTunes.plist

3. Search and replace with sed (or other method of your choosing) the following text
from: MgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
to: MgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

We piped the output to a new file.

/bin/cat /private/tmp/com.apple.iTunes.plist | /usr/bin/sed s/MgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/MgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ > /private/tmp/com.apple.iTunesNew.plist

4. Convert the new file to binary plist file with plutil.

/usr/bin/plutil -convert binary1 /private/tmp/com.apple.iTunesNew.plist

5. Copy the new file back into the appropriate folder: ~/Library/Preferences/com.apple.iTunes.plist.

Launch iTunes and voilà, the Sidebar should show up.

We will further test to be sure, but so far it’s looking quite promising.

MS Office 2011 Mac

Today I came across an issue with the Macintosh version of Microsoft Office 2011. Microsoft issued an the 14.4.1 update back in April. It turns out it causes some issues with the Volume license copy. I found some other posts on the internet complaining about this issue.

So to explain.

We have a software management server deploying our software. We are using Munki, but there are others, Casper from Jamf, Filewave, etc… I was setting up a brand new computer, and Munki pushed out the Office install and all subsequent updates, a settings package which also deals with the licensing. What we found that upon launching MS Word, we are prompted to enter the license key, when it should not be needed. Turns out, that applying the 14.4.1 patch, causes this to happen. In an experiment, I did the install, and prevented 14.4.1 from going out. Launched MS Word, and it opened just fine. I then applied the patch, and then it still worked fine.

So to recap, if you are installing MS Office 2013 from scratch, make sure you launch it before applying the latest 14.4.1 patch. Then patch.

Locked Console issues

When Apple updated to Mac OS X 10.7.x, they changed the way the authentication dialog box works when the console is locked by a user.

In the past, in OS versions 10.6 and older, if the screensaver was set to Ask For Password, when a user wanted to get back to the desktop, they would get a Name and Password field, usually with their name pre-filled in. In many cases, if an administrator had to get into the user’s session, the credentials of a local administrator (I have never tried it with a domain administrator with administration rights on the computer) could be entered instead, thus gaining access to the desktop.

Uses vary, from needing to fix stuff, or log the user off so others can use the computer, etc… This was also useful if the user forgot their password or for some reason was locked out from the domain services, and needed to gain access to save their work, etc…

Enter Mac OS 10.7+ (Lion.) Since then, the authentication dialog box has the user’s name in a non editable field, with only the password field allowing entry. Thus, only the logged in user can gain desktop access. If other users need that user to be logged off, draconian methods needs to be applied to forcibly boot the user off, one of such method is to forcibly reboot the system.

Just to clarify, in our environment we don’t use Fast User Switching.

I’m not a big fan of forcibly rebooting the computer. Unsaved work can get lost, and file corruption can happen, along with a host of other things.

While I was searching for something completely unrelated, I came across this Apple KB article HT5145 (http://support.apple.com/kb/HT5145).

Once the /private/etc/pam.d/screensaver is altered, it will allow a local administrator to gain desktop access if the user locks the console with the screensaver. In order to do so, the administrator can then press the Option-Return key, and be rewarded with a full authentication dialog box.

After reading the article, I came up with a script to implement the listed change. Here is a link to my script: https://github.com/awjohnso/UnlockScreenSaver.

If the script is stored on the computer, and say an Apple update reverses the changes, an administrator can remotely fire off the script with remote software such as ARD (Apple Remote Desktop).

To upgrade, or not to upgrade, that is the question…

During the fall, I’ve been asked by several people if they should upgrade to Mac OS X 10.9 aka Mavericks. My response is usually a bit complex.

In our labs (SINC Sites) we don’t roll out a new OS hot off the press. In our environment we have to be sure of several things:

  • The current software catalog will still function on the new OS.
  • Security and privacy concerns must be addressed.
  • Management of client workstations must be fully operational.
  • And other concerns.

So, before we roll out the new OS, we have to perform a great deal of testing, and possibly modifications of some functions etc.

Now, for individual users, it’s usually less intense then that. But regardless, of what anyone wants, my advice is always to wait a few minor version releases. This gives Apple the time to fix bugs or other problems not detected or left unresolved during the beta testing phase of development. I for one, will install it on a test computer not my prime computer. This way I get to mess around with it, as a user and under the hood administrator, which gives me the time to figure out what’s what.

Since Mavericks was released mid fall semester, and it was priced at $0.00, many people thought it would be “awesome” to upgrade to the latest and greatest right away. I mean extra features is always a good thing right?

Turns out that wasn’t the case. Some of the students who upgraded their computers found out that once 10.9 was installed they could no longer use some of the required web sites for assignments and tests. Other issues that surfaced was the work at home VPN. Issues with Java made using the VPN quite difficult to impossible, thus cutting faculty and students off from campus resources while at home.

So, to wrap up this post, my answer would be to wait. This allows the vendor to sort out any issues, and also for vendors of third party software to ensure compatibility. A mid semester update is not a recommended practice, especially if you depend on your computer throughout the semester. However, if you absolutely need one or more of the new features in the new release, then, what can I say, take the plunge, but remember that other things may break, so making a pre-upgrade backup is highly advisable in case you need to roll back.

Dual Booting Macs

By now, many have figured out that Apple’s switch to Intel chips opened the door to some neat things. One of these features is the ability to run the Microsoft Windows OS on Apple hardware. This can be accomplished in a few ways, either natively on the hardware (also known as Dual Booting) or via virtualization (through products like VMWare Fusion, and Parallels Desktop.)

Back in January of 2008, TLT released it’s first set of Dual Boot Macintosh computers in the SINC Sites. Initially we had many questions we needed to answer before we could feel good about the Dual Boot solution. Some of the issues were:

  1. How do we ensure that both OSes are patched regularly.
  2. How do we keep the respective OS from seeing the other, since a dormant OS is a weak OS.
  3. How we get users to pick which OS they wanted to use.

I am going to focus on the third item listed for this post.

We wanted to give users the ability to pick the OS they wanted to use. But how to accomplish this? At the time we came across two products which could accomplish the task, but unfortunately they each had some tradeoffs.

The first program is called BootPicker, originally written by Michael Bombich, which is no longer supported. I’m sure some copies can be found floating around the Internet. If you have good Google skills it will turn up somewhere.

The other item was rEFIt. Since rEFIt is no longer being actively developed, the rEFIt  code was forked into rEFInd.

BootPicker works on the premise that administrators want to be able to have remote management over the clients at all times. BootPicker lets the computer boot up to the Mac OS, and before the login window appears, the picker displays your choice menu, and this is where the computer waits for input. Should a user pick Mac OS X, then the picker ends and the login window comes up. Should the user pick Windows, then the computer shuts down and then re-boots to Windows.

rEFIt, on the other hand, kicks in before the computer fully boots up. In fact rEFIt and rEFInd all hand off to the respective boot loaders after a selection is made.

So advantage rEFIt/rEFInd for speed and how quickly you can get to the Windows OS since you don’t have to wait for a re-boot. However, BootPicker has the advantage for allowing an admin to remotely manage the computer while it’s sitting at the OS choice window. rEFIt/rEFInd don’t allow for that.

We ended up choosing BootPicker since we wanted to make sure we could remotely manage our computers and ensure patches were being applied.

TLT has since stopped Dual Booting for the SINC site computers. Getting two OSes on the machines and other odds and ends significantly increased our work load, and complexity. With the growth and improvements to the Virtual SINC Site, a decision was made to drop Dual Booting and have the users launch the Citrix-Virtual SINC Site to access Windows based software absent from the Macintosh catalog.

Only in one instance is there a Dual Boot setup. There is a Macintosh teaching station connected to a SMART board. Running the SMART tools with the Virtual SINC Site layered over the Mac OS, proved to be a bit cumbersome. Since BootPicker wasn’t officially supported anymore, to get the user to reboot into Windows, the user uses a special account to log into the Mac, which then reboots the computer to Windows.

Profile Manager for Mac OS X

I’ve had mixed feelings regarding Apple’s new client management tool, called Profile Manager. It’s supposed to combine managing iOS and Mac OS X in one neat interface complete with push notification. Allegedly, it’s supposed to replicate Apple’s OD/MCX setup for the Mac OS X environment. I’ve been toying with it on and off since v.1 which came with Mac OS X 10.7, Lion, Server.

I just got the new Mavericks (Mac OS 10.9 Server) version up and running, and I’m still disappointed in it. One of my issues is the Custom Settings area, where a plist can be uploaded so an app or other setting can be managed. Every time I try to upload a plist file, I get an cryptic error from the Server. My Google-fu has not turned up any solutions for this issue.

My other gripe is the obvious lack of the ability to further customize the default settings. Unless I’m missing something, in OD/MCX I was able to edit the plist file that was generated from one of the default settings. I made heavy use of that to further tweak the interface and look of the SINC Site Macintosh computers.

The push notification in Profile Manager is nice, although I still have to test that for the computers sitting in the un-routable network. However, that problem might go away soon.

Enter mcxToProfile. I was made aware of mcxToProfile some time ago, but since the advent of Mavericks, I’m forced to abandon OD/MCX and go the profile route. mcxToProfile to profile is a python script written by Tim Sutton.

For now, until I feel that Profile Manager has matured enough, I plan to extract my OD/MCX settings with mcxToProfile, which then makes a profile out of it. I will have to tweak the profiles a bit due to new settings or obsolete settings in Mac OS X 10.9. I then plan to develop a way of applying them to all the lab computers.

The easiest way is to create packages and deploy it via Munki. But, over the next week or so, I plan to see what’s my best option.