Wednesday, November 9, 2011

Creating VMs from an existing VDI file

We recently had a request to install VirtualBox and a custom VDI for a course. Students with little technical backgrounds needed to be able to launch and create a individual instance of an Ubuntu virtual machine.
We did some experimentation on configuring the virtual machine with a shared VDI file and using VirtualBox snapshots, as well as shadow disk images, for saving changes. We decided the best course was to drop a copy of the entire VDI to the students Desktop and use VirtualBox's command line tool to configure them a VM.
We stored the VDI inside a disk image and delivered it to the /Users/Shared folder of each Mac. We then had VirtualBox installed. Using Platypus we wrapped a script that will copy the VDI, create the VM, and start it.
If the VDI already exists on the desktop, the VM is created and launched. If the VM is already created, then it's launched right away.
This provides students and faculty with a simple way to launch and use the virtual machine provided to them.
Here is the script that we use: https://github.com/rustymyers/scripts/blob/master/shell/createVBoxVM.sh

After writing this, I got a lot of comments that we should check out Vagrant. http://vagrantup.com/
Do your self a favor and always google what you want to do before writing something from scratch to do it!

Thursday, October 6, 2011

Thank You Steve.

My words feel lacking in empathy today. It feels futile to try to think of what to type. So I leave you with these pictures instead...

Picture of an original Macintosh with a "Thank You" note written by Rusty Myers October 6th, 2011.

Wednesday, August 17, 2011

Maya 2012 Semaphore Issues

Recently I had the pleasure of installing Maya 2012 in a lab environment. To qualify "lab", it is a non-admin multi-user lab.

Maya 2012 seems to have a bit of an issue with cleaning itself up after running. Someone much more informed on the subject has guided me through the discovery of the issues and how to deal with them.

In a nutshell, Maya is leaving Semaphore ipc instances after quiting the program, which also persist after a user logs out! A reboot of the system will clear the semaphore, but it asking a little too much to have a user reboot after quitting Maya 2012.

So, how do I know this? After launching Maya 2012 (Or Mudbox 2012), try running this command:

$ ipcs -b
IPC status from as of Fri Aug 12 14:41:35 EDT 2011
T ID KEY MODE OWNER GROUP QBYTES
Message Queues:

T ID KEY MODE OWNER GROUP SEGSZ
Shared Memory:

T ID KEY MODE OWNER GROUP NSEMS
Semaphores:
s 327680 0xb3536107 --ra-r--r-- rzm102 psuguest 3

You can see it's being left there even after log out! To remove it, you need to pass the ID to the ipcrm command:

$ ipcrm -s 327680

That will clear the semaphore ipc and allow Maya to once again launch. I've noticed that the error in the console about "ACE_SV_Semaphore_Complex: Permission denied" still occurs, but has no effect on Maya launching.

To fix this for the labs, I'm suggesting having the logout hook clean this up using this code:

IPCSUCKS=`ipcs -b | grep -A 1 -i semaphores|tail -1|awk '{print $2}'`
sudo ipcrm -s "$IPCSUCKS"

This should clear the instance of the ipc from Semaphores. I'm not sure this is the best solution because there could be multiple ipc's from semaphore or it could be for something other than Maya. However, I'm running out of time this semester and I need to move on.

A bug report needs to be filled with Autodesk to ask them to change the permissions on the semaphore so that other non-admin users can overwrite that instance. As Frogor from ##osx-server explained: "They need to be setting it up as --ra-ra-r--".

This is a quick and dirty blog post, please forgive the assumptions, spelling mistakes, grammar mistakes, and overall vagueness.

For more information on IPC and Semaphores, check out wikipedia:

And if you are more knowledgeable about these issues, please post in the comments so we may all learn!

Tuesday, August 16, 2011

Firmware Passwords on New Macs

According to the KB article TS3554, new Macs have a different way of resetting the firmware password, should you forget it. More on that later.

What I want to discuss is the new tool for setting your firmware password.

No Longer is the nvram used when configuring the password. The nvram settings are outright ignored. The Firmware Password Utility shipped by Apple has been updated to accommodate this change.

I am unsure of WHERE or HOW the passwords is configured, but I do know that Apple has a new binary tool to configure it via the command line. "setregproptool" can now be used to configure your firmware password.

Finding information of this update from the MacEnterprise email list points me to the install DVD that shipped with our newest iMacs.

To locate this tool, Tomas has given you a path to it on the USB flash drive that came with Macbook Airs. Well, the DVD path is almost the same, except for a few slight changes to the media name.

Here are some directions to get the binary tool:
1) Insert your Install DVD to your Mac.
2) Open the Terminal.app from /Applications/Utilities/
3) Paste in this line:
cp /Volumes/Mac\ OS\ X\ Install\ DVD/Applications/Utilities/Firmware\ \
Password\ Utility.app/Contents/Resources/setregproptool ~/Desktop/

The setregproptool should appear on your desktop, assuming the name of the DVD is the same as I have in my command. YMMV.

Now that you have the binary tool, you can distribute it by whatever means you find the best. Scripts can be written to call it. You can now have fun.

The setregproptool has a nice little man page to help you configure your firmware password. In our case, we simply want a firmware password when choosing the "option boot" or command mode.

$ setregproptool -m "command" -p secretpassword

If a password is currently set, it will prompt you for it.

As Thomas Larkin talks about in his MacE post, the check flag (-c) was not correctly reporting that the password was set. While this may be an issue for some people it was of little concern for me, at least, for now!

Now that you can set your firmware password again, lets talk about what happens when you FORGET it!

A) Don't forget it.
B) If you do, you have to boot your Mac into the firmware password screen.

This screen provides a hash that can be sent to Apple. I assume Apple has a way to reverse this hash and respond to you with the firmware password.

All things considered, you should never see this screen. Hopefully you have a way to manage your passwords that is secured and is available to at least two people.

When that inevitable time comes that someone forgets it, your going to have to jump through some hoops.

If your an Authorized Service Center, or a Authorized Self Service Center for Apple, you can talk to the friendly TPSS support staff to have your hash reversed.

If your not, your going to need to find someone that is. That means a trip to your closest Apple Store or other Authorized Service Center.

Please avoid the hassle and don't forget your firmware password.

Good luck!

Links:

MacEnterprise Post:
http://groups.google.com/group/macenterprise/browse_thread/thread/3092c51a73d064c4?pli=1

Apple KB on resetting the FW password:
http://support.apple.com/kb/TS3554

Products Affected as of 08/2011
MacBook Air (Late 2010), MacBook Pro (17-inch, Early 2011), MacBook Pro (15-inch, Early 2011), MacBook Pro (13-inch, Early 2011), MacBook Air (Mid 2011), iMac (27-inch, Mid 2011), iMac (21.5-inch, Mid 2011), Mac mini (Mid 2011)