All posts by asmodai

Setting up SublimeText 3 for Ansible

I love using SublimeText 3 for Ansible work, especially after some minor tweaks. The packages I have installed are: Ansible syntax highlighting, ApplySyntax, Jinja2 syntax support, SublimeLinter, and SublimeLinter-pyyaml.

For ApplySyntax you want to change the user settings to contain something like the following below. It’s based on the best practices for Ansible directory layout, but with one change, I prefer to have playbooks in their own subdirectory.

    "syntaxes": [
            "syntax": "Ansible/Ansible",
            "rules": [
                { "file_path": ".*/defaults/.*.ya?ml$" },
                { "file_path": ".*/handlers/.*.ya?ml$" },
                { "file_path": ".*/meta/.*.ya?ml$" },
                { "file_path": ".*/tasks/.*.ya?ml$" },
                { "file_path": ".*/vars/.*.ya?ml$" },
                { "file_path": ".*/inventory/group_vars/.*" },
                { "file_path": ".*/inventory/host_vars/.*" },
                { "file_path": ".*/inventory/.*" },
                { "file_path": ".*/playbooks/.*.ya?ml$" }
            "syntax": "Jinja2/Syntaxes/Jinja Templates",
            "rules": [
                { "file_path": ".*/templates/.*.j2$" }

The above will ensure that the Ansible syntax highlighting gets used for the regular expressions defined in the file_path matches.

Then in the SublimeLinter user settings make sure that syntax_map contains an entry "ansible": "yaml". This will ensure that all views marked with the Ansible file type will now automatically use the SublimeLinter-pyyaml linter.

Revisiting Mercurial and file keyrings

In a previous post I talked about setting up an encrypted file based keyring store for Mercurial. With some recent updates of the Python keyring modules, the setup changed a little bit again.

The file-backed keyrings got moved out to the keyrings.alt package. $HOME/.local/share/python_keyring/keyringrc.cfg needs to be adjusted as follows:


VirtualBox corrupting VM metadata file

So after a recent update of VirtualBox from 5.0.20 to 5.0.22 I found that a Windows 7 image I have suddenly didn’t work anymore. Worse yet, everything was empty or reset to default values.

You can most likely recover from this by following these steps:

  • Close VirtualBox (although you might not want to until you safeguarded vbox-prev if you find out you don’t have a versioned backup file)
  • Go to the directory you have your VM files
  • In here look for your faulty image’s directory and cd in
  • Look for a vbox file with the same name as your image, but most likely containing a version number as the settings/metadata file got upgraded. DO NOT lose this file.
  • Run a vboxmanage list vms
  • Copy the UUID listed as inaccessible
  • Run vboxmanage unregistervm <UUID>
  • Copy the backup vbox file over the existing, wrong one
  • Run vboxmanage registervm /path/to/file.vbox
  • Most likely VBoxManage will error out with an error about a conflict with DVD images with different UUIDs (in my case)
  • Edit the vbox file, remove offending line (in the case of the DVD image, might be more difficult with other error cases)
  • Run vboxmanage registervm /path/to/file.vbox again
  • VBoxManage should now not error out
  • Start VirtualBox and your VM should be ok again

Of course the behaviour from VirtualBox is downright dangerous here. If there is such a conflict or error it should NEVER mess around with your metadata file and thus corrupt it. This is one of the biggest sins in software programming. Only after you successfully start an application are you allowed to write out any updates of settings files and whatnot.

Meld in TortoiseHg

I like Meld as a visual diff/merge tool. You can also use it as the default in TortoiseHg. Open TortoiseHg’s Workbench. Go to File » Settings, make sure the global settings tab is active. Click Edit File, if it doesn’t yet exist create a section called [extdiff], and under [extdiff] add cmd.meld = /path/to/meld. For Windows it would be something like cmd.meld = C:\Program Files (x86)\Meld\meld.exe. From the command line you should be able to use hg meld to get your diff shown in Meld.

Dark Souls: Prepare to Die Edition, constant UAC popups

So on a recent reinstall of my Dark Souls: Prepare to Die Edition in Steam I was confronted with a UAC (User Account Control) popup from Windows every single time I started it. Dark Souls used to use Games for Windows Live in the past. As some point it switched over to Steamworks. Unfortunately the installscript.vdf file was not adjusted to reflect this. It still tries to call the gfwlivesetup part of the setup because it never completes and the required registry key is missing. So because of this is falls into an infinite check, popup UAC cycle.

To fix this, open up the registry editor by running regedit, navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Valve\Steam\Apps\211420, in the right pane right-click, select New » DWORD (32-bit) Value and name it gfwlivesetup. Double-click this newly created entry and enter 1 for the value. Exit the registry editor and start Dark Souls. You should not see the UAC popup anymore.

Ansible, URLs, proxies and connection refused

So today I was trying to fix a problem with the deployment of some software with Ansible. I am using get_url in combination with a http_proxy environment setting in order to pull a file in from a HTTP URL. However, when I ran the playbook I was greeted with a [Errno 111] Connection refused error message. After fixing the proxy to have the netblock properly configured I tested again and was again greeted by the error. The problem became more confounding when I ran a test with curl on the command line using the proxy parameters, this test actually worked. So the proxy was running as it should. After some long testing and trying to figure out just what was going wrong, I replaced the get_url with a command: curl set up to test if it might be Ansible itself. The output of curl was enlightening, it turned out the HTTP URL was 301 redirecting to another HTTP URL, which in turn was 302 redirecting to a HTTPS URL! And since I wanted to be explicit I had not added the https_proxy environment variable.

The problem however now comes in how to to fix this. Is it documentation? Ansible code fix? Python code fix?

Android and Material Design

The new Android version, so far called ‘L’ and most likely winding up being called Lollipop when it will be released, has a new visual style called Material Design.

For Android this change of visual style means that the code base also needs to service both old API deployments (lower than v20) as well as the new ones (v21 and upwards). In effect this means you have to create res/layout-v21 and res/values-v21 directories to customize the layout and modify the styles for the new API.

In your module’s build.gradle you have to change the compileSdkVersion to 'android-L' and the targetSdkVersion to 'L'. If you have any dependencies on support-v4 or appcompat-v7 you need to switch those to v21.+ to pick up future updates, such as a different release candidates up to the released version.

Revisiting Android and support libraries (support-v4 and appcompat-v7)

I have previously written on this subject, but now I am using IntelliJ IDEA 13 with the latest Android SDK of this writing (September 2014) and when you create a project you might be greeted by an error message like the following:

Error:Gradle: A problem occurred configuring project ':projectname'.
> Could not resolve all dependencies for configuration ':projectname:_debugCompile'.
   > Could not find any version that matches
     Required by:
   > Could not find any version that matches
     Required by:

The Android SDK has switched over to Gradle since I last wrote about it. In this case the default setup already searches the local libs directory under Projectname/projectname for any jars to compile with the build of the application. But if you would follow the instructions from my previous post the chance is high that you keep running into this problem. Aside from the installation of the Android Support Library, you will also need to install the Android Support Repository in order to make dependency resolution work. Do verify that your Projectname/ contains a set property for sdk.dir that points to the root of your locally installed Android SDK.

Now, you might still run into problems. The thing is that in your Projectname/projectname/build.gradle you generally want to have the compile lines for support-v4 and appcompat-v7 match the version of your targetSdkVersion. So this might become:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile ''
    compile ''

These numbers can be found in the SDK under extras/android/m2repository/com/android/support under the respective entries for appcompat-v7 and support-v4. If you would use + for the version identifier, you run the chance of picking up the latest version, including release candidates and this might break your build. So in this case being explicit is better than depending on it implictly.

Edit: On second thought, it might be better to use 20.+ or 20.0.+ for the version identifier in order to automatically pick up bugfix releases down the line. Looking at the release notes of the support library it seems that Google is quite strict in sticking to semantic versioning.

Mercurial, python keyring 3, and mercurial keyring

In an earlier post I documented how to set up an encrypted file store for your keyring. With recent versions of Python keyring (at least 3 and up) the CryptedFileKeyring backend got removed and replaced by EncryptedKeyring. So in your $HOME/.local/share/python_keyring/keyringrc.cfg you need to now have the following: