Windows cacls.exe cheatsheet

The windows cacls.exe is a confusing, un-intuitive, and poorly documented tool. I'm recording a few of my more frequent examples here as a cheat sheet.

Give all users full control over all files and subdirs in a directory:

cacls.exe target_dir /t /e /g Users:f

[SOLVED] fatal error C1902: Program database manager mismatch; please check your installation

I was running the Visual Studio compiler by ssh'ing into a cygwin SSH server running on windows and running "cmd /c msbuild" which gave me this error:

fatal error C1902: Program database manager mismatch; please check your installation

But strangely, if I connected over RDP and ran exactly the same command in a windows shell...it worked. This email led me to the solution so I'm giving it a signalboost. It turns out that if you authenticate to the SSH server with a key you run as a different user and in a login environment that somehow messes up the visual studio build process. You can see the difference by running whoami as below.

If you authenticated with a password you should see a proper username (in this case vagrant):

$ /cygdrive/c/WINDOWS/system32/whoami.exe
build-pc\vagrant

But if you authenticate with a key, you'll see something like this:

$ /cygdrive/c/WINDOWS/system32/whoami.exe
grr-build-pc\cyg_server

Building a Windows Vagrant VM to use WinRM

You basically have two options for talking to windows vagrant VMs. WinRM or SSH. For ssh you'll need to install cygwin's openssh server, or another ssh server. If you use cygwin you'll end up ssh'ed into the cygwin environment, which may confuse scripts you use that are expecting regular windows command shell. If that's the case, you need winrm. I followed these instructions, which also have some great tips for reducing the box size.

But I still had some trouble setting up WinRM. As a quick and dirty check before you go to the effort of creating the box, add a port forward in virtualbox for the winrm port 5985:

And try hitting this URL:

$ wget http://localhost:5985/wsman
--2015-03-23 13:25:00--  http://localhost:5985/wsman
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:5985... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:5985... connected.
HTTP request sent, awaiting response... 405 
2015-03-23 13:25:00 ERROR 405: (no description).

You should get a successful connection, but an error as above because this isn't a valid winrm call. If that doesn't work make sure you followed the vagrant instructions for enabling winrm. Try running this inside the VM:

winrm quickconfig -q

In my case quickconfig complained that:

WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

But when I looked at network connections in the network connection manager I couldn't change the VirtualBox host networking adapter type as advised. This is a known problem where Windows 7 network connections get stuck in public, I fixed it with this tool from Microsoft. You can verify your winrm configuration is functioning correctly by installing pywinrm and running a command:

In [33]: import winrm

In [34]: s = winrm.Session('127.0.0.1', auth=('vagrant', 'vagrant'))

In [35]: s.run_cmd('ver').std_out
Out[35]: '\r\nMicrosoft Windows [Version 6.1.7601]\r\n'

Switching a git checked-out repo from SSL to SSH

Occasionally I'll clone a git repo (or a tool will do it for me) over SSL like this:

$ git clone https://github.com/google/gxui.git
Cloning into 'gxui'...
remote: Counting objects: 906, done.
remote: Total 906 (delta 0), reused 0 (delta 0), pack-reused 905
Receiving objects: 100% (906/906), 477.53 KiB | 0 bytes/s, done.
Resolving deltas: 100% (548/548), done.
Checking connectivity... done.
$ cd gxui/
$ git remote -v
origin https://github.com/google/gxui.git (fetch)
origin https://github.com/google/gxui.git (push)

But later on I might want to push code, which is more convenient over SSH since I have a github key added. Switch the remote like this:

git remote set-url origin git@github.com:google/gxui.git
$ git remote -v
origin git@github.com:google/gxui.git (fetch)
origin git@github.com:google/gxui.git (push)

Install a OS X .dmg or .pkg from the commandline

If you have a dmg, you need to attach it:

hdiutil attach GPG_Suite-2015.02-b5-1161.dmg

Then install it:

sudo installer -pkg /Volumes/GPG\ Suite/Install.pkg -target /

Packaging an existing virtualbox vm for use with vagrant

It's not super-obvious from the vagrant documentation, but you can use the "vagrant package" command to package up an existing VirtualBox VM. This will shut down the VM, create the metadata.json, and zip up the disk. To use it you need to know the name that VirtualBox has for your VM, list them with:

$ VBoxManage list vms
"ubuntu-lucid64" {aaaabbbb-cccc-dddd-1234}
"CentOS build" {aaaabbbb-cccc-dddd-1234}

Package up the vagrant VM with:

$ vagrant package --base "CentOS build" --output centos_5.11_64
$ vagrant box add centos_5.11_64 --name centos_5.11_64

Workaround for broken vagrant up ssh "unsupported encryption type"

Vagrant is still not playing nicely with SSH certificates loaded into ssh-agent. In my case this seemed to only be a problem during provisioning (i.e. "vagrant up"), using "vagrant ssh" after the box was up worked fine. The error is:

The private key you're attempting to use with this Vagrant box uses
an unsupported encryption type. The SSH library Vagrant uses does not support
this key type. Please use `ssh-rsa` or `ssh-dss` instead. Note that
sometimes keys in your ssh-agent can interfere with this as well,
so verify the keys are valid there in addition to standard
file paths.

You can try clearing out some keys from ssh agent with:

$ ssh-add -D
All identities removed.

Except ssh is probably lying if you're running goobuntu, the keys are still there. There's all sorts of confusion about this behaviour, which seems to be the fault of gnome-keyring, which allegedly only allows you to delete manually added keys. If your SSH certs are automatically loaded it seems like you're out of luck.

By far the easiest workaround is to simply temporarily disable the ssh agent:

SSH_AUTH_SOCK="" vagrant up