Month: January 2014

Obscure VirtualBox Errors

You might get this weird VirtualBox error if, for instance, you’ve tried to start a virtual machine in GUI mode, but haven’t yet logged into the system graphically. This is most important on headless Linux or OS X systems.

$ vboxmanage startvm "Some Virtual Machine"
Waiting for VM "Some Virtual Machine" to power on...
VBoxManage: error: The VM session was aborted
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SessionMachine, interface ISession

To get around this make sure you add --type headless to the vboxmanage startvm call, or just use the VBoxHeadless machine starter.

Not Bothering

VirtualBox has a pretty good remote desktop server built in, but securing it can be a pain if you’re actually doing it properly, using Transport Layer Security (TLS) certificates and the like.

I’ve created a script to handle setting these certificates and username/password pairs, based on the VirtualBox manual, but it seems almost overkill to me for my use case.

There’s an easier way to do it if you’re not trying to set up a whole bunch of headless VirtualBox instances for many different people. The trick is to set the authentication type to Null, but only start the Remote Desktop server on localhost:

If you’re using the secure-box-rdp.sh script I wrote, this is simplified to:

./secure-vbox-rdp.sh -v virtual-machine-name -N -P remote-desktop-port

You just provide the virtual machine name and port number you’d like to use, and the script does the rest.

Then, all you have to do is set up an SSH tunnel into the virtual machine host, and none of the VMs set up this way are exposed to the outside world. Better still, it’s not clear how hard of a security audit the VirtualBox TLS implementation has gone through, but SSH is the constantly-reviewed bedrock of internet security.

Using plink on windows, it looks something like:

plink -v -ssh -l yourloginname -L 5000:localhost:5000 -C -N some.domain.com

Using ssh, it looks something like:

ssh -fCNq -L 5000:localhost:5000 yourloginname@some.domain.com

Once the tunnel is connected properly, you can just connect to the virtual machines via localhost:VRDE_PORT, and all of the tunneled traffic is automatically encrypted, for the win!

rdc

Time-Robbing Python Errors

Ran into a problem while attempting to get Python provisioned automatically in Windows. I could install Python as an administrator, but when I would switch into a Limited User Account and attempt to use pip or virtualenv, I’d get nothing but obscure failure.

The key phrase that kept popping up was:

“WindowsError: [Error 183] Cannot create a file when that file already exists: ‘C:\\Documents and Settings\\Administrator\\.distlib'”

as distlib kept trying to put things into the admin account by default.

To make sense of the error, I had to dig into the closest code to the WindowsError that was thrown, which looked like this:

Lo and behold, setting the LOCALAPPDATA environment variable to some writeable folder to which the Limited user has acccess will fix the issue. But it strikes me as a place where the os.path.expandvars() call should probably check the APPDATA environment variable too.

And, for whatever odd reason, it seems like the os.path.expanduser() call uses the user credentials associated with the Python executable or something, because at no point as I’m running this code as a Limited User, do I specify that I want the code to act like it is an Administrator. It’s a bit odd.

In any case, it works, but the solution is less than obvious.

Provisioning OS X and Disabling Unnecessary Services

I’ve been messing with system provisioning quite a bit lately. i.e. How can I repeatably and consistently configure a system to a known state?

I’ve posted a script to Github that performs provisioning to free up as much RAM as possible on an OS X server system.

OS X is a hairy operating system though, since Apple provides little to no detail about the system services they enable on a freshly-installed machine. This is annoying.

Here are some techniques I use to determine which services can be disabled, and what subsystems they relate to.

First of all, you can get a sense of all of the services run at launch time by running launchctl list:

I’ve already disabled a number of services using the Github script, but maybe there are more to be disabled in the launchctl list.

For example: soagent, what is it and what does it do?

The find out, read the com.apple.soagent.plist file in /System/Library/LaunchAgents.

The launchd.plist manpage explains some of these settings.

The process has something to do with iChat. Since I don’t care whether iChat is running on my provisioned machine, I can try disabling this process:

launchctl -w /System/Library/LaunchAgents/com.apple.soagent.plist

If the system is stable with soagent disabled, then everything’s fine. Same thing goes for the CalendarAgent, the SocialPushAgent, and sharingd.

Another example: What is tccd?

So tccd appears to be the little popup that appears when application wants to dig into your more personal information. If the provisioned machine is being used as a server w/no logged in UI user, this can also be disabled.

The same pattern of analysis, reading plist files, and looking into the application bundles themselves if necessary, can be applied to all of the launched services.