The Right Stuff

WinDbg Commands

Alexander Groß — Sat, 24 Jul 2010 20:45:03 GMT

I just finished watching Ingo Rammer’s sessions on debugging from NDC 2010:

While I consider myself experienced in debugging with Visual Studio I still didn’t know the Ctrl+B trick Ingo shows in the first session to create breakpoint groups, for example to break on all methods named WriteLine.

Ingo’s second session goes into detail how to start with WinDbg. During his talk Ingo wrote down quite a lot of WinDbg commands that I copied and extended a bit for my own reference.

# Use debugger according to architecture that is being debugged.

# Drag exe onto WinDbg to start debugging.

# Debugging services:
# 1. Using Global Flags
#  - On "Image File" tab, enter service exe
#  - Set debugger to cdb.exe -server tcp:port=1234
# 2. Start service
# 3. Start WinDbg
#  - connect to remote session: tcp:server=localhost,port=1234
# Also works (unsecured) over networks

!help

.loadby sos mscorwks # CLR 2
.loadby sos clr      # CLR 4, both after the debuggee has loaded the CLR
.chain               # Shows loaded extensions

sxe <event code> # Stop
sxn <event code> # Notify
sxi <event code> # Ignore
# ... on <event code> exceptions (for example, <event code> = clr)

g            # Go
.cls         # Clear screen

!pe          # Print exception
!clrstack    # Display stack trace
!clrstack -a # Stack trace with additional information (parameters and locals)
# If there is no stack information the JIT optimized the code away (i.e. inlining).
!dumpstack   # Another way to get the stack trace

!u <address> # Unassemble code at <address>
# Look for calls into managed code (to the right) to find the line/call that caused the exception.
# <assembly>_ni = Native image

!do <address> # Dump object
!da <address> # Dump array
# To copy addresses: Left double-click a numeric value, double right-click to copy it to the command line.

~            # Show all (managed and unmanaged) threads
!threads     # Show managed threads
~2s          # Switch to thread 2 (#2 in the unnamed column)
!runaway     # Show thread execution times (user-mode) - to find hanging threads

!dumpheap    # Show heap information, 1 line per instance
!dumpheap -stat # Heap statistics, most memory-consuming at the bottom. MT = class "pointer"
!dumpheap -stat -type TextBox # Show instances of classes containing "TextBox"
!dumpheap -type TextBox
!dumpheap -mt <type> # Dumps all instances of "TextBox" or <type>
!gcroot <address> # Why is the instance at <address> in memory?
# Domain = new GC root that reference <address> (~ static instance)
# Ignore WeakReferences, look for (pinned) references

# Create dumps from code:
[DllImport("DbgHelp.dll", SetLastError = true]
static extern bool MiniDumpWriteDump(
    IntPtr hProcess,
    int processId,
    IntPtr fileHandle,
    int dumpType, // 0x0 or 0x6 for managed code
    IntPtr exceptionInfo,
    IntPtr userInfo,
    IntPtr extInfo);

How To Set Up A Git Server On Windows Using Cygwin And Gitolite

Alexander Groß — Sun, 28 Mar 2010 14:48:18 GMT

Updated on 2012-03-06 to reflect the changes to the Gitolite installation process.

For obvious reasons, a couple weeks ago my team made the switch to Git. Hosting a Git server on Windows is by all means possible, and there are two options:

Gitosis is a Python-based solution that provides basic Git hosting with per-repository permissions. Shannon Cornish has an excellent two-part guide how to set that up.
Gitolite, a Perl-based rewrite of Gitosis, is a more advanced Git server that has a lot more configuration options. For example, it’s possible to specify who is able to force a push to a Git branch, an operation that is possibly problematic when working in teams.

A notable aspect of both solutions is that repository configuration and permissions management is done through Git itself. Over time, you will build a versioned history of the server configuration. Without further ado, let’s get started!

You’ll see that we have to deal with Cygwin and SSH mostly. Gitolite’s installation is pretty easy and does not require a lot of work by itself. Getting the Windows Server in a condition where it handles SSH takes most of our time.

Installing Cygwin
Connecting Cygwin to Windows Security
Setting Up the SSH Server
Enabling SSH Client Access
Verifying SSH Password Access
1. Creating Your SSH Identity
Making the SSH Server Aware of Your SSH Identity
Installing Gitolite

What You Need

A Windows Server (I’m using Windows Server 2008 x86) with permissions to log in as an Administrator.
An internet connection to download Cygwin.

Installing Cygwin

Download the Cygwin setup program to C:\Cygwin and launch it. For this guide, I’ve used the current version 1.7.2.
Select “Install from Internet”, click Next.
Leave Root Directory as the default, C:\Cygwin, and install for all users. Click Next.
Select C:\Cygwin\pkg as the Local Package Directory. Actually it doesn’t really matter what the directory is, you can delete it after the installation. Click Next.
Select the Internet Connection you prefer: Direct, IE Settings or enter a manual proxy. Click Next.
Select a mirror near your location, click Next.
Acknowledge the “Setup Alert” warning about your installation.
In the packages list, select the following packages by clicking on “Skip” text in the “New” column. When you clicked, the version that will be installed is displayed instead of “Skip”.
- Net | openssh
- Devel | git
- Editors | vim
Click Next and wait for the installer to complete.
You may choose to add icons to the Desktop and Start Menu. Click Complete.

I recommend leaving the setup.exe in place, as you can use the installer to add, remove or upgrade Cygwin packages later.

Repeat the process on your local machine, this time with an extended set of packages to install:

Net | openssh
Devel | git
Devel | git-completion (optional)
Devel | git-gui (optional)
Devel | git-svn (optional, if you want to commit to SVN)
Devel | gitk (optional)

Connecting Cygwin to Windows Security

In preparation for the SSH server installation in the next section, we need to provide Cygwin with means to impersonate a SSH user as a Windows user with public key authentication. You can read more about integrating with Windows Security in the Cygwin documentation.

On the server, open C:\Cygwin in Explorer.

Locate Cygwin.bat, right-click and choose “Run as Administrator”.

Copying skeleton files.
These files are for the user to personalise their cygwin experience.

They will never be overwritten nor automatically updated.

`./.bashrc' -> `/home/Administrator//.bashrc'
`./.bash_profile' -> `/home/Administrator//.bash_profile'
`./.inputrc' -> `/home/Administrator//.inputrc'

Administrator@GIT-SERVER ~
$

Execute /bin/cyglsa-config

Warning: Registering the Cygwin LSA authentication package requires
administrator privileges!  You also have to reboot the machine to
activate the change.

Are you sure you want to continue? (yes/no)

Type yes.

Cygwin LSA authentication package registered.

Activating Cygwin's LSA authentication package requires to reboot.

Reboot the machine.

Setting Up the SSH Server

SSH will encrypt and authenticate connections to your Git repositories. SSH will use public key authentication to check if the user is permitted to access the server. Once the user got past the SSH security check Gitolite will take over handling the request.

When the Git server finished rebooting:

Open a new Cygwin Bash prompt by running C:\Cygwin\Cygwin.bat as Administrator.

Execute ssh-host-config

Administrator@GIT-SERVER ~
$ ssh-host-config
*** Info: Generating /etc/ssh_host_key
*** Info: Generating /etc/ssh_host_rsa_key
*** Info: Generating /etc/ssh_host_dsa_key
*** Info: Creating default /etc/ssh_config file
*** Info: Creating default /etc/sshd_config file
*** Info: Privilege separation is set to yes by default since OpenSSH 3.3.
*** Info: However, this requires a non-privileged account called 'sshd'.
*** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.
*** Query: Should privilege separation be used? (yes/no)

Type yes.

*** Info: Note that creating a new user requires that the current account have
*** Info: Administrator privileges.  Should this script attempt to create a
*** Query: new local account 'sshd'? (yes/no)

Type yes.

*** Info: Updating /etc/sshd_config file


*** Warning: The following functions require administrator privileges!

*** Query: Do you want to install sshd as a service?
*** Query: (Say "no" if it is already installed as a service) (yes/no)

Type yes.

*** Query: Enter the value of CYGWIN for the daemon: []

Just hit the Return key.

*** Info: On Windows Server 2003, Windows Vista, and above, the
*** Info: SYSTEM account cannot setuid to other users -- a capability
*** Info: sshd requires.  You need to have or to create a privileged
*** Info: account.  This script will help you do so.

*** Info: You appear to be running Windows 2003 Server or later.  On 2003
*** Info: and later systems, it's not possible to use the LocalSystem
*** Info: account for services that can change the user id without an
*** Info: explicit password (such as passwordless logins [e.g. public key
*** Info: authentication] via sshd).

*** Info: If you want to enable that functionality, it's required to create
*** Info: a new account with special privileges (unless a similar account
*** Info: already exists). This account is then used to run these special
*** Info: servers.

*** Info: Note that creating a new user requires that the current account
*** Info: have Administrator privileges itself.

*** Info: No privileged account could be found.

*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will only be used by registered services.
*** Query: Do you want to use a different name? (yes/no)

Type no.

*** Query: Create new privileged user account 'cyg_server'? (yes/no)

Type yes.

*** Info: Please enter a password for new user cyg_server.  Please be sure
*** Info: that this password matches the password rules given on your system.
*** Info: Entering no password will exit the configuration.
*** Query: Please enter the password:

Type and confirm a secure password for the SSH service account. This account will later fork processes on behalf of the user logged in via SSH. You will see another slew of text (which you should read) and then a blinking prompt.
Open the Windows Firewall and create an exception for port 22/tcp. Thanks to Marcel Hoyer for the command line equivalent:
```
netsh advfirewall firewall add rule dir=in action=allow localport=22 protocol=tcp name="Cygwin SSHD"
```
Execute sc start sshd

Enabling SSH Client Access

Next we will enable SSH access for the git user that will be used to access repositories.

Create a new Windows user account named git with a secure password. That user should have no password expiration. You can also delete any group membership.
In the Cygwin Bash prompt, execute mkpasswd -l -u git >> /etc/passwd
Close the Bash prompt (Ctrl + D) and log off from that machine. The rest of the setup process will be done from your machine.

Verifying SSH Password Access

On your workstation, open a Cygwin shell.

Execute ssh git@git-server

you@YOUR-MACHINE ~
$ ssh git@git-server
The authenticity of host 'git-server (172.16.0.42)' can't be established.
RSA key fingerprint is 13:16:ba:00:d3:ac:d6:f2:bf:36:f4:28:df:fc:d5:26.
Are you sure you want to continue connecting (yes/no)?

Type yes.

Warning: Permanently added 'git-server,172.16.0.42' (RSA) to the list of known hosts.
git@git-server's password:

Enter the password for the git account and you will be presented with a prompt from git-server.

Copying skeleton files.
These files are for the user to personalise their cygwin experience.

They will never be overwritten nor automatically updated.

`./.bashrc' -> `/home/git//.bashrc'
`./.bash_profile' -> `/home/git//.bash_profile'
`./.inputrc' -> `/home/git//.inputrc'

git@git-server ~
$

Press Ctrl + D or execute logout to end the session and you’ll be back on your machine’s prompt.

Creating Your SSH Identity

The next steps to create two SSH identities. The first is required to access the soon-to-be Git server, the second will be used to install and update Gitolite. Execute the following commands on your local machine.

We’re about to generate a private and public key pair for you that will be used to authenticate SSH connections. Execute ssh-user-config
```
*** Query: Shall I create an SSH1 RSA identity file for you? (yes/no)
```

Type no.

*** Query: Shall I create an SSH2 RSA identity file for you? (yes/no)

Type yes.

*** Info: Generating /home/agross/.ssh/id_rsa
Enter passphrase (empty for no passphrase):

Type and confirm a passphrase. You can omit the passphrase if you want, but that makes you less secure when you loose your private key file.
```
*** Query: Do you want to use this identity to login to this machine? (yes/no)
```
Type no. (Unless you want to remotely log in to your workstation with that key. Don't worry, this can be enabled later.)
```
*** Query: Shall I create an SSH2 DSA identity file for you? (yes/no)
```

Type no.

*** Info: Configuration finished. Have fun!

Repeat the steps above using ssh-keygen -f ~/.ssh/gitolite-admin. We need that key for the installation process.

Making the SSH Server Aware of Your SSH Identity

In order to be able to log-in to the Git server as the git user using your gitolite-admin SSH identity, execute ssh-copy-id -i ~/.ssh/gitolite-admin git@git-server. This adds the gitolite-admin public key to the list of authorized keys for the git account.

you@YOUR-MACHINE ~
$ ssh-copy-id -i ~/.ssh/gitolite-admin git@git-server
git@git-server's password:
Now try logging into the machine, with "ssh 'git@git-server'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Verifying that public key authentication works, on the next log-in you do not have to enter git@git-server’s password.

you@YOUR-MACHINE ~
$ ssh -i ~/.ssh/gitolite-admin git@gitserver
Last login: Fri Mar 26 02:04:40 2010 from your-machine

git@git-server ~
$

You are now ready to install Gitolite!

Installing Gitolite

The Gitolite installation process documentation is sufficient to get you started. There's just one more thing that you need to do on Windows.

Upgrades to newer versions of Gitolite are easy and run like the first-time installation. That is, you can just repeat the process outlined below, probably with a new Gitolite version. This installation method requires a SSH login, but we’ve just set-up things this way.

Before proceeding, we need to copy the non-admin public SSH key to the server.
```
$ scp -i ~/.ssh/gitolite-admin ~/.ssh/id_rsa.pub git@gitserver:your-name.pub
```
Connect to the Git server by executing ssh -i ~/.ssh/gitolite-admin git@gitserver
We need to prepare your .bashrc file for the installation process to succeed. We'll do it with the Vim editor, which might seem a bit basic at first. Actually, it's very powerful.
1. On the command prompt, type vim .bashrc to open up the editor.
2. Depending on whether someone created the .bashrc file before, it might not be empty. Navigate to the bottom by pressing G (uppercase is important).
3. Press the letter o to enter Vim’s insert mode on a new line (o = "open a line").
4. Type the following into the text file: PATH=/home/git/bin:$PATH
5. Press ESC to leave Vim’s insert mode.
6. Type :wq and hit Return to save the file and close Vim. To dismiss any changes made in the last step and exit Vim, type :q! and hit the Return key.
Back on the command prompt, type source .bashrc to update the PATH environment variable.

Next, clone to the Gitolite bits as outlined in the installation documentation.

git@gitserver ~
$ git clone git://github.com/sitaramc/gitolite
Cloning into 'gitolite'...
remote: Counting objects: 5360, done.
remote: Compressing objects: 100% (1806/1806), done.
remote: Total 5360 (delta 3708), reused 5118 (delta 3498)
Receiving objects: 100% (5360/5360), 1.79 MiB | 655 KiB/s, done.
Resolving deltas: 100% (3708/3708), done.

git@gitserver ~
$ gitolite/src/gl-system-install
using default values for EUID=1005:
/home/git/bin, /home/git/share/gitolite/conf, /home/git/share/gitolite/hooks

git@gitserver ~
$ gl-setup -q ~/your-name.pub
creating gitolite-admin...
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /home/git/repositories/testing.git/
[master (root-commit) 3725b39] gl-setup -q /home/git/your-name.pub
 2 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/your-name.pub

gl-setup will create the .gitolite.rc config file that needs our attention. We'll use Vim again.
1. On the command prompt, type vim .gitolite.rc to open up the editor.
2. Press the letter O (uppercase this time) to enter Vim’s insert mode on a new line before the current line.
3. Type the following into the text file: $ENV{PATH} = "/usr/local/bin:/bin:/usr/bin";
4. Press ESC to leave Vim’s insert mode.
5. Type :w and hit Return to save the file.
6. Apply any changes to the well-commented configuration you want to make.
  You can navigate using the cursor keys, and enter insert mode by pressing i. Leave insert mode by hitting ESC.
7. Type :wq and hit Return to save the file and exit Vim. To dismiss any changes made in the last step and exit Vim, type :q! and hit the Return key.
Leave the SSH session by pressing Ctrl + D.

Once the installation is finished, you can clone the gitolite-admin repository to your desktop.

$ git clone git@gitserver:gitolite-admin.git

To add repositories or change permissions on existing repositories, please refer to the Gitolite documentation. The process uses Git itself, which is awesome:

Make changes to your copy of the gitolite-admin repository in your home directory.
Commit changes locally.
Push to the Gitolite server and let it handle the updated configuration.

If you ever want to update or manage the Gitolite server, you can still SSH into the server with

$ ssh -i ~/.ssh/gitolite-admin git@gitserver

Wrapping Up

This guide as been pretty long, longer than I wish it had been. Following Shannon Cornish’s example, I wanted it to be rather too verbose than too short. At least, I did appreciate the detail of Shannon’s instructions when I installed Gitosis back in December. I’ve just begun to grasp the power of Unix – leveraging a set of tiny programs to orchestrate a system.

With the setup you have now in place, you can do anything you like – it’s a complete Git server. However, if you want to publish your server on the internet there’s more you will want to take care of. I will go into that in a future post, detailing some of Cygwin’s security features that helped us reduce the number of attacks on our server. Also, I will take a look at how you can enable the Gitweb Repository Browser using the lighttpd web server.

Rezept: Eintopf

Alexander Groß — Sat, 27 Mar 2010 13:33:54 GMT

1 Suppengemüse (Lauch, Sellerie, Karotten, Petersilie)
300 g Hackfleisch
400 g Kartoffeln
Nudeln oder Spätzle

Kartoffel schälen und in mundgerechte Stücke schneiden. Kartoffelstücke und Nudeln separat in Salzwasser kochen. In Scheiben geschnittetenen Lauch, gehackte Zwiebeln und Fleisch anbraten. Mit etwas Mehl überstäuben und verrühren. Beiseite stellen.

Das restliche kleingeschnittene Gemüse in einem großen Topf kochen. Wenn das Gemüse gar ist, die anderen Zutaten hinzugeben und gut durchmischen. Ziehen lassen, fertig.

Machine.Specifications Templates For ReSharper

Alexander Groß — Wed, 03 Mar 2010 13:56:54 GMT

A couple of days ago Hadi Hariri posted his set of MSpec (Machine.Specifications) templates for ReSharper. ReSharper’s templating system helps you type less repeated code. On top of that, ReSharper templates are much richer when compared to what’s built into Visual Studio. Plus, you edit them with a decent editor instead of hacking XML files.

Like Hadi, I also created a couple of templates specific to MSpec over the course of the last year or so and found them often to reduce the amount of text I have to write. ReSharper Templates are divided into three categories, with at least one MSpec template in each.

Legend

foo denotes an editable part of the template
| denotes where the cursor will be put upon expansion

File Template

Basically, this is just a new C# file with a single MSpec context in it.

using System;

using Machine.Specifications;

namespace ClassLibrary1
{
  [Subject(typeof(Type))]
  public class When_Context
  {
    Establish context = () => { | };

    Because of = () => { };

    It should_ = () => { };
  }
}

Live Templates (a.k.a. Snippets)

Live Templates provide expansion of keyword-like identifiers. For example cw (Tab) will expand to Console.WriteLine();

Name	Expanded
`spec`	A new context, similar to what the File Template above creates.
`est`	`Establish context = () => { \| };`
`bec`	`Because of = () => { \| };`
`it`	`It should_observation = () => { \| };`
`fail`	`It should_fail = () => Exception.ShouldNotBeNull(); static Exception Exception;`
`l`	`() => \| ;` Only valid for assignments. For example: `var x = l (Tab) var x = () => \| ;`
`ll`	`() => { \| };` Only valid for assignments.

Surround Templates

Surround Templates are useful when you want to wrap a block of code with other code, for example, an if statement (this is one that’s built-in).

Unit testing frameworks almost always have means to assert that are particular test should fail with a specific exception, for example by marking the test method with the ExpectedExceptionAttribute.

The MSpec way of handling/expecting exceptions is to surround the code in Because with Catch.Exception:

public class When_a_negative_amount_is_deducted
{
  static Exception Exception;
  static Account Account;

  Establish context =
    () => { Account = new Account(); };

  Because of =
    () => { Exception = Catch.Exception(() => Account.Deduct(-1)); };

  It should_fail =
    () => Exception.ShouldNotBeNull();
}

There’s a surround template named Catch.Exception that we can make wrap the call to Account.Deduct:

Create the context with just the Account field, Establish and the Because. Select the highlighted code.

public class When_a_negative_amount_is_deducted
{
  // Account field and Establish cut for brevity.

  Because of =
    () => { Account.Deduct(-1); };
}

Press the shortcut for ReSharper | Edit | Surround With Template, select "Catch.Exception" from the list of available templates.

public class When_a_negative_amount_is_deducted
{
  // Account field and Establish cut for brevity.

  Because of =
    () => { Exception = Catch.Exception(() => { Account.Deduct(-1); }); };
}

Navigate out of the Because field, for example by pressing the (End) key. Type fail (a Live Template, see above) and press (Tab).

public class When_a_negative_amount_is_deducted
{
  // Account field and Establish cut for brevity.

  Because of =
    () => { Exception = Catch.Exception(() => { Account.Deduct(-1); }); };
  fail(Tab)
}

Marvel at the amount of code you didn't have to write.

public class When_a_negative_amount_is_deducted
{
  // Account field and Establish cut for brevity.

  Because of =
    () => { Exception = Catch.Exception(() => { Account.Deduct(-1); }); };

  It should_fail =
    () => Exception.ShouldNotBeNull();

  static Exception Exception;
}

Download

Download Machine.Specifications Templates For ReSharper

How We Practice Continuous Integration And Deployment With MSDeploy

Alexander Groß — Sat, 06 Feb 2010 17:35:15 GMT

About two years ago I quit the pain of CruiseControl.NET’s XML hell and started using JetBrains TeamCity for Continuous Integration. While being a bit biased here, I have to admit that every JetBrains product I looked at is absolutely killer and continues to provide productivity on a daily basis.

I’ve been a fan of Continuous Integration ever since. I figured the next step in improving our practice was not only to automate building/compiling/testing the application, but also deploy it either by clicking a button or based on a schedule. For example, updates to this blog’s theme and the .NET Open Space web sites are automated by clicking the “Run” button on my local TeamCity instance.

Compare that button click to what we are forced to do manually for some projects at work. Every time we roll out a new version someone will:

Build the deployment package with TeamCity.
Download the deployment package, which is usually a ZIP containing the application and database migrations.
RDP into the production server.
Upload the deployment package.
Shut down the web application, Windows services, etc.
Overwrite the binaries and configuration files with the current versions from the deployment package.
Sometimes we have to match up and edit configuration files by hand.
Upgrade the database by executing *.sql files containing migrations in SQL Server Management Studio.
Restart web application and Windows services, etc.
Hope fervently that everything works.

I believe you can imagine that the manual process outlined has a lot of rope to hang yourself with. An inexperienced developer might simply miss a step. On top of that, implicit knowledge of which files need to be edited increases the bus factor. From a developer and business perspective you don’t want to deal with such risks. Deployment should be well documented, automated and easy to do.

Deployment Over Network Shares Or SSH

When I first looked into how I could do Continuous Deployment there were not many free products available on the Windows platform. In a corporate environment you could push your application to a Windows network share and configure the web application through scripts running within a domain account’s security context.

A different story is deployment over an internet connection. You would want to have a secure channel like a SSH connection to copy files remotely and execute scripts on the server. This solution requires SSH on the server and tools from the Putty suite (i.e. psftp) to make the connection. I had such a setup in place for this blog and the .NET Open Space web sites, but it was rather brittle: psftp doesn’t provide synchronization, integration with Windows services like IIS is not optimal and you’re somewhat limited in what you can do on the server.

MSDeploy

Last year, Microsoft released MSDeploy 1.0 which was updated to version 1.1 last week. MSDeploy is targeted to help with application deployment and server synchronization. In this article, I will focus on the deployment aspects exclusively. Considering the requirements for deployment, MSDeploy had everything I asked for. MSDeploy either

runs as the Web Deployment Agent Service providing administrators unrestricted access to the remote machine through NTLM authentication, or
runs as the Web Deployment Handler together with the IIS Management Service to let any user run a specified set of operations remotely.

Both types of connections can be secured using HTTPS, which is great and, in my opinion, a must-have.

I won’t go into the details of how MSDeploy can be set up because these are ~~well~~ documented. What I want to talk about what concepts we employ to deploy applications.

The Deployment Workflow

With about three months of experience with MSDeploy under our belts, we divide deployments into four phases:

Initial, minimal manual preparation on the target server
Operations to perform in preparation for the update
Updating binaries
Operations to perform after the update has finished

The initial setup to be done in phase 1 is a one-time activity that only occurs if we decide to provision a new server. This involves actions like installing IIS, SQL Server and MSDeploy on the target machine such that we can access it remotely. In phase 1 we also create web applications in IIS.

Further, we put deployments into two categories: Initial deployments and upgrade deployments. These only differ in the operations executed before (phase 2) and after (phase 4) the application files have been copied (phase 3). For example, before we can update binaries on a machine that is running a Windows service, we first have to stop that service in phase 2. After updating the binaries, that service has to be restarted in phase 4.

Over the last couple of weeks, a set of operations have been identified that we likely execute in phase 2 and 4.

Operation	Description	During Initial Deployment	During Upgrade	Before Or After Deployment
Set-WebAppOffline	Shuts down a web application by recycling the Application Pool and creating App_Offline.htm	No	Yes	Before
Set-WebAppOnline	Deletes App_Offline.htm	No	Yes	After
Create-Database	Creates the initial database	Yes	No	After
Update-Database	Run migrations on an existing database	No	Yes	After
Import-SampleData	Imports sample data to an existing database for QA instances	Yes	No	After
Install-Service	Installs a Windows service, for example one that runs nightly reports	Yes	Yes	After
Uninstall-Service	Stops and uninstalls a Windows service	No	Yes	Before

It’s no coincidence that the operations read like PowerShell Verb-Noun cmdlets. In fact, we run operations with PowerShell on the server side.

The deployment directory that will be mirrored between the build server and the production machine looks like the one depicted in the image to the right.

The root directory contains a PowerShell script that implements the operations above as PowerShell functions. These might call other scripts inside the deployment directory. For example, we invoke Tarantino (created by Eric Hexter and company) to have our database migrations done.

$scriptPath = Split-Path -parent $MyInvocation.MyCommand.Definition

# Change into the deployment root directory.
Set-Location $scriptPath

function Create-Database()
{
    & ".\SQL\create-database.cmd" /do_not_ask_for_permission_to_delete_database
}

function Import-SampleData()
{
    & ".\SQL\import-sample-data.cmd"
}

function Upgrade-Database()
{
    & ".\SQL\update-database.cmd"
}

function Install-Service()
{
    & ".\Reporting\deploy.ps1" Install-Service
    & ".\Reporting\deploy.ps1" Run-Service
}

function Uninstall-Service()
{
    & ".\Reporting\deploy.ps1" Uninstall-Service
}

function Set-WebAppOffline()
{
    Copy-Item -Path "Web\App_Offline.htm.deploy" -Destination "Web\App_Offline.htm" -Force
}

function Set-WebAppOnline()
{
    Remove-Item -Path "Web\App_Offline.htm" -Force
}

# Runs all command line arguments as functions.
$args | ForEach-Object { & $_ }

# Hack, MSDeploy would run PowerShell endlessly.
Get-Process -Name "powershell" | Stop-Process

The last line is actually a hack, because PowerShell 2.0 hangs after the script has finished.

Rake And Configatron

As you might remember from last week’s blog post we use Rake and YAML in our build scripts. Rake and YAML (with Configatron) allow us to

build the application,
generate configuration files for the target machine, thus eliminating the need to make edits, and
formulate MSDeploy calls in a legible and comprehensible way.

Regarding the last point, please consider the following MSDeploy command line that synchronizes a local directory with a remote directory (think phase 3). PowerShell operations will to be performed before (-preSync, phase 2) and after the sync operation (-postSyncOnSuccess, phase 4).

"tools/MSDeploy/msdeploy.exe" -verb:sync -postSyncOnSuccess:runCommand="powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command C:/Crimson/deploy.ps1 Create-Database Import-SampleData Install-Service Set-WebAppOnline ",waitInterval=60000 -allowUntrusted -skip:objectName=filePath,skipAction=Delete,absolutePath=App_Offline\.htm$ -skip:objectName=filePath,skipAction=Delete,absolutePath=\\Logs\\.*\.txt$ -skip:objectName=dirPath,skipAction=Delete,absolutePath=\\Logs.*$ -preSync:runCommand="powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command C:/Crimson/deploy.ps1 Set-WebAppOffline Uninstall-Service ",waitInterval=60000 -usechecksum -source:dirPath="build/for-deployment" -dest:wmsvc=BLUEPRINT-X86,username=deployer,password=deployer,dirPath=C:/Crimson

The command line is convoluted and overly complex, isn’t it? Now please consider the following Rake snippet that was used to generate the command line above.

remote = Dictionary[]
    
if configatron.deployment.connection.exists?(:wmsvc) and configatron.deployment.connection.wmsvc
    remote[:wmsvc] = configatron.deployment.connection.address
    remote[:username] = configatron.deployment.connection.user
    remote[:password] = configatron.deployment.connection.password
else
    remote[:computerName] = configatron.deployment.connection.address
end

preSyncCommand = "exit"
postSyncCommand = "exit"

if configatron.deployment.operations.before_deployment.any?
    preSyncCommand = "\"powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command #{"deploy.ps1".in(configatron.deployment.location)} #{configatron.deployment.operations.before_deployment.join(" ")} \""
end

if configatron.deployment.operations.after_deployment.any?
    postSyncCommand = "\"powershell.exe -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command #{"deploy.ps1".in(configatron.deployment.location)} #{configatron.deployment.operations.after_deployment.join(" ")} \""
end

MSDeploy.run \
    :tool => configatron.tools.msdeploy,
    :log_file => configatron.deployment.logfile,
    :verb => :sync,
    :allowUntrusted => true,
    :source => Dictionary[:dirPath, configatron.dir.for_deployment.to_absolute.escape],
    :dest => remote.merge({
        :dirPath => configatron.deployment.location
        }),
    :usechecksum => true,
    :skip =>[
        Dictionary[
            :objectName, "filePath",
            :skipAction, "Delete",
            :absolutePath, "App_Offline\\.htm$"
        ],
        Dictionary[
            :objectName, "filePath",
            :skipAction, "Delete",
            :absolutePath, "\\\\Logs\\\\.*\\.txt$"
        ],
        Dictionary[
            :objectName, "dirPath",
            :skipAction, "Delete",
            :absolutePath, "\\\\Logs.*$"
        ]
    ],
    :preSync => Dictionary[
        :runCommand, preSyncCommand,
        :waitInterval, 60000
    ],
    :postSyncOnSuccess => Dictionary[
        :runCommand, postSyncCommand,
        :waitInterval, 60000
    ]

It’s a small Rake helper class that transforms a Hash into a MSDeploy command line. That helper also includes console redirection that sends deployment output both to the screen and to a log file. The log file is also used to find errors that may occur during deployment (see below).

For your convenience, these are the relevant parts of the configuration, expressed in YAML and parsed with Configatron.

some_config:
  deployment:
    location: C:/Crimson
    operations:
      before_deployment: [Set-WebAppOffline, Uninstall-Service]
      after_deployment: [Create-Database, Import-SampleData, Install-Service, Set-WebAppOnline]
    connection:
      wmsvc: true
      address: BLUEPRINT-X86
      user: deployer
      password: deployer

What I Haven’t Talked About

What’s missing? An idea that got me interested was to partition the application into roles like database server, reporting server, web application server, etc. We mostly do single-server deployments, so I haven’t built that yet (YAGNI). Eric Hexter talks about application roles in a recent blog entry.

Another aspect where MSDeploy unfortunately doesn’t shine is error handling. Since we run important operations using the runCommand provider (used by -preSync and -postSyncOnSuccess) we would want to fail when something bad happens. Unfortunately MSDeploy, to this day, ignores errorlevels that indicate errors. So we’re back to console redirection and string parsing. This functionality is already in my MSDeploy helper for Rake, so you can rely on it to a certain degree. Manually scanning log files for errors, at least for the first couple of automated deployments is recommended, though.

Since we’re leveraging PowerShell on the server, why should we have to build the PowerShell script handling operations ourselves? I can imagine deploying the PowerShell-based PSake build tool and a PSake build script containing operations turned build targets. This will allow for common build script usage scenarios like task inspection (administrators would want that), having task dependencies, error handling and so on.

Wrapping Up

In this rather long post, I hope I could provide you with information how MSDeploy can be used to deploy your applications automatically. For us, over the last couple of weeks, MSDeploy in combination with our Rakefiles has helped us tremendously deploying an application that’s currently under development: The pain of delivering current versions to the customer has gotten a breeze.

Rake, YAML and Inherited Build Configuration

Alexander Groß — Sat, 30 Jan 2010 14:03:51 GMT

We’ve been using Rake for quite a while at work. Sometime last year I sat down and converted our ~30 KB NAnt build scripts to Rake, a light-weight Ruby build framework with low friction and no XML. Since then I have written a bunch of Rake tasks to support our builds (we use TeamCity).

I started a bit out of the blue, because frameworks like Albacore didn’t exist back then and other .NET-specific task collections didn’t fit our needs or simply were inconvenient to use.

Without prior Ruby experience it was also a great opportunity to learn Ruby and give the language and design concepts a spin. I have to admit, I like the fluent style of Ruby, it’s almost like the language tries to stay out of your way.

YAML

Soon after I started building the first Rake script I needed to configure the build for different environments. Like: in production, we have to use another database server. You want to externalize such information into a configuration file. Having database connection strings hard coded in your application’s App.config will make tailoring the application for deployment tedious and error-prone. I’ve been there, and I don’t recommend it!

I came across YAML which is an intuitive notation for configuration files (amongst others):

development:
  database:
    server: (local)
    name: Indigo

qa:
  database:
    server: DB
    name: Indigo_QA

production:
  database:
    server: DB
    name: Indigo_Production

Is that legible? I think so!

We use the configatron Ruby Gem to read such files and dereference configuration information in the build script.

configatron.configure_from_yaml 'properties.yml', :hash => 'production'

puts configatron.database.server
# => 'DB'

puts configatron.database.name
# => 'Indigo_Production'

YAML’s “Inheritance”

Another useful aspect of YAML is that it supports a simple form of inheritance by merging hashes.

qa: &customer_config
  database:
    server: DB
    name: Indigo_QA

production:
  <<: *customer_config
  database:
    name: Indigo_Production

Unfortunately this kind of inheritance has some subtleties as it wouldn’t work as you would expect. I read the snippet above like the production configuration inherits all values from qa and overwrites the database.name. Let's see:

configatron.configure_from_yaml 'properties.yml', :hash => 'production'

puts configatron.database.server.nil?
# => true
# Huh? That should be "DB".

puts configatron.database.name
# => 'Indigo_Production'

Actually, there is an article describing the problem with merging hashes in YAML files that I found after our build broke in interesting ways after loading an incomplete configuration. The proposed solution is either to duplicate all configuration information between qa and production, or to use more anchors (&foo) and merge references (<<: *foo). I think both clutters a YAML file unnecessarily.

Custom Inheritance

After I identifying why composition doesn’t work as one would expect let’s see what we can do about it.

I went with solution based on a convention that inheritance should be defined using a default_to configuration entry.

qa:
  database:
    server: DB
    name: Indigo_QA

production:
  default_to: qa
  database:
    name: Indigo_Production

The default_to entry in the production section refers to another section that the configuration will be inherited from. You could also build inheritance chains like production → qa → default and additionally use ordinary transparent YAML hash merges.

Instead of initializing configatron from the YAML file, we’ll preprocess the deserialized YAML (basically, a Hash), evaluate the configuration inheritance chain and then pass the Hash to configatron:

yaml = Configuration.load_yaml 'properties.yml', :hash => 'production', :inherit => :default_to
configatron.configure_from_hash yaml

puts configatron.database.server.nil?
# => false

puts configatron.database.server
# => 'DB'

puts configatron.database.name
# => 'Indigo_Production'

The code for the Configuration class that accounts for evaluating the inheritance chain is up on GitHub.

Visual Studio Tip: Setting Indent Width and Tabs/Spaces Quickly Using Macros

Alexander Groß — Sun, 24 Jan 2010 16:07:16 GMT

Over the last years I’ve been contributing to several Open Source software projects, just to name the most recent:

All of the above projects follow their own style how to lay out the source code using indents. It seems like everybody has a different opinion you would have to cater for, for example:

Indenting is done with tabs
4-space indents
2-space indents

Often times these conventions are implicit, you have to read the source code to see the actual style the authors follow. It is encouraged to apply these guidelines to your patches ensure they will be accepted.

I often switch between developing for projects, so before writing a single line of code I have to hit Visual Studio’s Tools | Options | Text Editor Options dialog and change the indent settings to match the project’s conventions.

This has become very tedious, additionally, I often forget to adjust the indent settings before writing code. (Perhaps I forget it because it’s so annoying.)

To scratch that itch I sat down and wrote some Visual Studio macros that apply the most commonly used settings:

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics

Public Module Fonts
    Sub TwoSpaces()
        Dim textEditor As Properties

        textEditor = DTE.Properties("TextEditor", "AllLanguages")
        textEditor.Item("IndentStyle").Value = vsIndentStyle.vsIndentStyleSmart
        textEditor.Item("TabSize").Value = 4
        textEditor.Item("IndentSize").Value = 2
        textEditor.Item("InsertTabs").Value = False
    End Sub

    Sub FourSpaces()
        Dim textEditor As Properties

        textEditor = DTE.Properties("TextEditor", "AllLanguages")
        textEditor.Item("IndentStyle").Value = vsIndentStyle.vsIndentStyleSmart
        textEditor.Item("TabSize").Value = 4
        textEditor.Item("IndentSize").Value = 4
        textEditor.Item("InsertTabs").Value = False
    End Sub

    Sub OneTab()
        Dim textEditor As Properties

        textEditor = DTE.Properties("TextEditor", "AllLanguages")
        textEditor.Item("IndentStyle").Value = vsIndentStyle.vsIndentStyleSmart
        textEditor.Item("TabSize").Value = 4
        textEditor.Item("IndentSize").Value = 4
        textEditor.Item("InsertTabs").Value = True
    End Sub

    Public Sub NormalFonts()
        SetFontSize(10)
    End Sub

    Public Sub LargeFonts()
        SetFontSize(14)
    End Sub

    Sub SetFontSize(ByVal size As Int32)
        Dim textEditor As Properties

        textEditor = DTE.Properties("FontsAndColors", "TextEditor")
        textEditor.Item("FontSize").Value = size
    End Sub
End Module

These macros are associated with toolbar buttons:

The first two buttons are associated to the LargeFonts and NormalFonts macros that set the editor font size. I like to invoke these when doing presentations. No more fiddling with Tools | Options to ensure your audience is able to read the code on the wall.

The last three buttons should be self-explaining, they’re to quickly set tabbed, two-space and four-space indents, respectively.

Using the Microsoft Solver Foundation Add-In for Excel

Alexander Groß — Sun, 17 Jan 2010 14:52:36 GMT

After listening to the Hanselminutes episode on Microsoft Solver Foundation (MSF) I decided it’s time to give it a shot today. Solver Foundation seems to be a solution to a set of constrained problems I sometimes face:

Sharing costs and calculating minimal money transfers after trips with my friends, where each friend spent some money.
Giving out questions to attendees of our User Group “Boot Camps”: Speakers prepare ~20 questions, ranging from easy to moderate levels. We assign each attendee an easy question and one to chew a bit upon. Further, every question should be given out to two attendees, so in case someone doesn’t make it to the meeting we’re still able to cover the question.

Something I don’t remember Scott Hanselman and his guest talking about is that Solver Foundation comes with an Excel Add-In that is supposed to make creating models ~~easy~~ easier, no code needed. Along with the “Solver Foundation for Excel Primer” document that is installed along with the binaries I figured Excel would be a good way to start looking into Solver Foundation.

After the MSI ran, I started Excel but didn’t find the Solver Foundation tab that’s advertised in the primer. The COM Add-Ins dialog said something about that the Add-In could not be loaded. Nice! Luckily the Event Viewer was more helpful in terms of error messages where I found this beauty of an exception:

Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException:
Customization could not be loaded because the application domain could not be created.
---> System.IO.FileLoadException: Could not load file or assembly 'MicrosoftSolverFoundationForExcel, Version=1.0.6.4890, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

My first guess was that an old MSF assembly was referenced and I decided to go with an assembly binding redirect for excel.exe. Didn’t help. The next step was to get into the innards of VSTO deployment. What I found in the MicrosoftSolverFoundationForExcel.vsto and MicrosoftSolverFoundationForExcel.dll.manifest files wasn’t surpising: Several references to old versions of MSF. None of which were deployed by the MSI installer, so Excel trying to load such dependencies failed.

<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.8.6048"…
<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.6.4890"…

I updated both references to the match the installed version 2.0.2.8632, just to find myself faced with another error saying that the manifest’s digital signature is broken.

Now was time to contact my friend Lars Keller who is an expert in VSTO development. Lars told me that I would have to re-sign the .vsto and .manifest files to make the signature reflect my changes. The Office Development with Visual Studio blog has the full details.

I had to create a certificate that can be used for code signing:

makecert -r -pe -n "CN=Your Name" -b 01/01/2010 -e 01/01/2099 -eku 1.3.6.1.5.5.7.3.3 -ss My

Export the certificate as a PFX file using certmgr.msc
Create a backup copy of the MSF Excel Add-In .manifest and .vsto files
Open a Visual Studio Command prompt and navigate to the manifest's location
Make edits to the manifest file correcting the assembly versions of MicrosoftSolverFoundationForExcel to 2.0.2.8632

Update the digital signatures for both the manifest and the VSTO file:

mage.exe -update MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>
mage.exe -update MicrosoftSolverFoundationForExcel.vsto -appmanifest MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>

Restart Excel, the Solver Foundation tab should be on the ribbon

(Tested with Office 2010 beta.)

Rezept: Victoriaseebarsch auf dem Gemüsebett

Alexander Groß — Tue, 30 Jun 2009 19:32:27 GMT

das Filet eines halben Victoriaseebarschs (ungefähr 450 g)
1 unbehandelte Zitrone
1 rote Paprika
1 1/2 kleine Zucchini
5 Schalotten
5 kleine aromatische Tomaten
ein paar Blätter Basilikum und Zitronenmelisse
2 Zweige Rosmarin
1 Knoblauchzehe
100 g Butter
3 EL Olivenöl
50 ml trockener Weißwein
Salz, Pfeffer

Die Paprika bei großer Hitze ungefähr 10 Minuten im Ofen rösten. Nach dem Herausnehmen etwas erkalten lassen, die Schale abziehen und die Kerne entfernen. Die Paprika in Streifen schneiden.

Inwzischen die Schale der Zitrone mit einem höllisch scharfen Messer hauchdünn abschneiden. Die Zesten anschließend sehr fein hacken und zusammen mit ebenfalls kleingehackter Zitronenmelisse und 1 TL Zitronensaft unter 50 g weiche Butter rühren.

Den Fisch in 4 Stücke schneiden, mit Zitronensaft beträufeln und wieder kalt stellen.

Knoblauch, Zucchini und die Schalotten in dünne Scheiben schneiden, die Tomaten halbieren und den Strunk entfernen. Das Olivenöl in einer ofenfesten Pfanne erhitzen und anschließend Knoblauch, Zucchini, Schalotten und Tomaten zusammen mit dem Rosmarin anbraten. Mit einem Schuss Weißwein und ein paar Spritzern Zitronensaft ablöschen, salzen und pfeffern. Grob gehacktes Basilikum und die Paprikastreifen darübergeben und beiseite stellen.

Die restliche Butter mit etwas Zitronensaft in einer zweiten Pfanne zerlassen. Den Fisch einseitig salzen und langsam halb durchbraten. Anschließend jedes Stück Fisch mit einem Blatt Zitronenmelisse belegen. Den Fisch vorsichtig auf das Gemüsebett in der anderen Pfanne umheben und die Zitronensaftbutter darübergeben. Diese Pfanne mit Aluminiumfolie dicht abschließen und bei 80°C 20 Minuten im Ofen garziehen lassen.

Mit Spaghetti al dente servieren.

Rewriting Git History: Relocating Subversion URLs

Alexander Groß — Thu, 25 Jun 2009 18:59:52 GMT

Today we changed the URL of our Subversion server at work to a new domain. Subversion and TortoiseSVN offer a separate relocate command for that, which basically updates the local working copy metadata.

Not so for Git. Git keeps SVN metadata in two places: the commit log messages themselves which hold a git-svn-id entry for all commits that have been pushed to SVN, and in the .git/config file.

commit e82751b4872142679ba61e26fc0c57e97c698e8f
Author: agross 
Date:   Thu Jun 25 16:44:55 2009 +0000

    Adding FxCop to the code quality task

    git-svn-id: https://your.svn-server/svn/Crimson/trunk@67 8ed4a44c-bfb4-4748-a28a-fad9255c4788

[core]
	repositoryformatversion = 0
	filemode = false
	bare = false
	logallrefupdates = true
	ignorecase = true
[svn-remote "svn"]
	url = https://your.svn-server/svn/Crimson/trunk
	fetch = :refs/remotes/git-svn

To update the SVN URL it’s required to update the Git configuration file (an easy edit) and also to rewrite the commit log messages, updating the values of git-svn-id to reflect the new SVN server URL. The latter can be achieved with the git-filter-branch command which allows you to dissect the project history in interesting ways.

Having several local Git repositories to update, I went for the scripted solution. I found this article on how to change the SVN repository URL and added some scripting goodness to it (aside from fixing the syntactic errors). It worked pretty good for my ~10 repositories.

You pass two arguments:
- The old SVN URL, i.e. http://old.server
- The new SVN URL, i.e. https://new.server
- The old URL will be matched against git-svn-id entries with a regular expression, and the matched parts get replaced with the new URL.
Rewrite the commit log messages, thus updating git-svn-id
Create a backup copy of .git/config
Replace the old SVN URL in .git/config
Delete all metadata Git has aquired about SVN
Rebase against SVN, recreating the SVN metadata

#!/bin/sh

# Must be called with two command-line args.
# Example: git-svn-relocate.sh http://old.server https://new.server
if [ $# -ne 2 ]  
then
  echo "Please invoke this script with two command-line arguments (old and new SVN URLs)."
  exit $E_NO_ARGS
fi  

# Prepare URLs for regex search and replace.
oldUrl=`echo $1 | awk '{gsub("[\\\.]", "\\\\\\\&");print}'`
newUrl=`echo $2 | awk '{gsub("[\\\&]", "\\\\\\\&");print}'`

filter="sed \"s|^git-svn-id: $oldUrl|git-svn-id: $newUrl|g\""
git filter-branch --msg-filter "$filter" -- --all

sed -i.backup -e "s|$oldUrl|$newUrl|g" .git/config

rm -rf .git/svn
git svn rebase

Migrating SharePoint Content Databases To A New Farm While Keeping Security Settings

Alexander Groß — Sat, 25 Apr 2009 14:40:29 GMT

The server this blog is hosted on was upgraded recently, i.e. is now run on a new dedicated server. Actually, next to this blog there’s a lot more going on. We, a bunch of geeks, are self-hosting mail, web sites, blogs and some collaboration tools like SharePoint (Windows SharePoint Services, in our case). Yeah, SharePoint, a true beast in and of itself. I can’t tell you how much I do not miss developing software for it and setting up customer sites.

I wanted to make the move to the new server as smooth as possible for our SharePoint users. Because we do not use Active Directory to authenticate our users, we obviously had to migrate the SharePoint user accounts manually. That is, re-create each user on the new server giving them a random password and communicate the change.

Moving a SharePoint site is surprisingly pretty well documented on TechNet, but won’t tell you about one important aspect: When you move the site to a new farm and the site does not use Active Directory, you will have to set up security anew.

Why? Because SharePoint matches user accounts by their SID, a value that is unique for each user account, even across machines: OLDMACHINE\foo’s SID is different from NEWMACHINE\foo’s SID. Burdening the four site collection administrator with this task is simply a no-go.

During my research how to work around that I found the Dustin Miller’s excellent post “Fix those SIDs”. It describes the process of massaging a SharePoint site collection database to replace old SIDs with the account SIDs of the current machine. I’ve extended it a bit, because I also decided to rename the SharePoint Search account while moving to the new server (note the extra REPLACE in line 11).

DECLARE @login nvarchar(255), @SystemId varbinary(512)

DECLARE curUsers CURSOR LOCAL FOR 
SELECT tp_Login, tp_SystemID FROM UserInfo WHERE tp_Deleted = 0

OPEN curUsers
FETCH NEXT FROM curUsers INTO @login, @systemid

WHILE @@FETCH_STATUS = 0
BEGIN
    DECLARE @newLoginName AS nvarchar(255) = REPLACE(REPLACE(@login, 'OLDMACHINE', 'NEWMACHINE'), 'spsearch', 'sharepoint-search')
    DECLARE @newSID varbinary(85) = SUSER_SID(@newLoginName)
    
    IF @newSID IS NOT NULL
    BEGIN
        PRINT 'Resetting user ' + @login + ' to new login ' + @newLoginName  + ' with SID '
        PRINT SUSER_SID(@newLoginName)

        UPDATE UserInfo
        SET    tp_SystemID = SUSER_SID(@newLoginName),
               tp_Login = @newLoginName
        WHERE CURRENT OF curUsers
    END
    
    FETCH NEXT FROM curUsers INTO @login, @systemid
END

CLOSE curUsers
DEALLOCATE curUsers
GO

After the script ran, take a look at the UserInfo table and SELECT rows that still contain OLDMACHINE in the tp_Login column. This helps you get a quick overview of what accounts have been missed during account re-creation.

As an extra step, I found it appropriate to update the site’s user entry as well (the account name that shows up in the site’s user list when no full name is given) to reflect the new machine name.

UPDATE    [AllUserData]
SET       [nvarchar1] = REPLACE(REPLACE([nvarchar1], 'OLDMACHINE', 'NEWMACHINE'), 'spsearch', 'sharepoint-search'),
          [nvarchar2] = REPLACE(REPLACE([nvarchar2], 'OLDMACHINE', 'NEWMACHINE'), 'spsearch', 'sharepoint-search'),
          [nvarchar3] = REPLACE(REPLACE([nvarchar3], 'OLDMACHINE', 'NEWMACHINE'), 'spsearch', 'sharepoint-search')

ChkDskAll ‒ ChkDsk For All Drives

Alexander Groß — Sat, 14 Feb 2009 15:41:57 GMT

The Windows file systems (NTFS and FAT) are able to automatically detect if they are broken. You can even specify when that automatic check should be performed. But sometimes you would want to force a file system check, for example when Windows suddenly behaves strangely for no obvious reason. (For example last year, the day before I went on a month-long vacation, Vista suddenly refused to boot.)

In order to schedule a file system check for the next reboot you will have to

Open an elevated command prompt or log in as an administrator,
Run chkdsk <Drive>: /f,
Rinse and repeat for all installed drives.

This task isn’t easy for inexperienced users, especially given that they might not know about the chkdsk command line tool in the first place. They could use the UI, but would have to repeat the process for each and every drive nonetheless.

To make this task easier, I wrote a little .NET application that automates scheduling file system check for all drives at the next boot. Just double-click ChkDskAll.exe, enter administrative credentials and wait for the goodness to happen.

If a drive has already been scheduled for scanning, it won’t be scheduled a second time. To exclude drives from being included in the scan, have a look at ChkdskAll.exe.config. For example, TrueCrypt drives should be excluded if you do not mount them as fixed drives.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <!-- The list of excluded drives, e. g. "CDE". -->
        <add key="ExcludeDrives" value="YZ"/>
    </appSettings>
</configuration>

Download ChkDskAll binary and source code

Creating Remote Desktop Connection Files On The Fly With PowerShell

Alexander Groß — Fri, 13 Feb 2009 17:28:51 GMT

About a month ago I got myself an IBM Lenovo X301 laptop. It’s the third machine I regularly use: I have a desktop at work, one workstation at home and now there also is the sweet X301. Even with only the second machine at work in place I found it crucial to keep my work environments automatically in sync. Live Mesh has been of great help with that. Despite being a CPU hog at times, it’s a great tool to synchronize your files across machines.

Now with Remote Desktop Connection files (*.rdp) there is actually a bit more work involved than just syncing files. My workstations both have two monitors and I like Remote Desktop windows to be placed on the second monitor. The laptop, on the other hand just has a single display (surprise!) and less screen real estate. Because of the varying screen resolutions a RDP window on my home workstation will not fit the display area at work without obscuring other UI elements like the taskbar. On the laptop, the situation gets worse as the display is simply not large enough to fit my default window size of 1500x1024 pixels.

The dimensions and location of the Remote Desktop window is stored in the plain-text RDP file itself. A conceivable solution might be to create three RDP files per server, one for each of my machines. Actually this would involve touching three files every time I need to change some value for the connection. Horrible.

Fortunately there is PowerShell to the rescue. There’s even a script that you can use to create RDP files on the fly. You’ll have to patch line 178 to make it work (see below). Also make the Set-RDPSetting function global by uncommenting lines 87 and 216.

# Old
$content += @("${tempname}:$($datatypes[$tempname]):$tempvalue")

# New
$content += @("${tempname}:$($datatypes[$tempname]):$tempvalue" + [System.Environment]::NewLine)

Now that we're set to use the Set-RDPSetting function, let us create a script to create a RDP file in the system’s temporary folder. See the highlighted lines below, there are three hashtables:

$workstations for your workstations (mine are AXL, FIRIEL and EOWYN),
$servers for the RDP servers you want to connect to and
$defaults for default connection properties.

. c:\Path\To\Set-RDPSetting.ps1

$workstations = @{
	'AXL' = @{
		'desktopwidth' = 1500
		'desktopheight' = 1024
		}
	'FIRIEL' = @{
		'desktopwidth' = 1300
		'desktopheight' = 800
		}
	'EOWYN' = @{
		'desktopwidth' = 1300
		'desktopheight' = 800
		}
	}
	
$servers = @{
	'192.168.6.161' = @{
		'session bpp' = 24
		'domain' = 'DEVELOPMENT'
		}
	'host.with.ssl.certificate' = @{
		'session bpp' = 24
		'authentication level' = 2
		'disable wallpaper' = $true
		'desktopwidth' = 1280
		'desktopheight' = 1024
		}
	}

# http://dev.remotenetworktechnology.com/ts/rdpfile.htm
$defaults = @{
	'allow desktop composition' = $true
	'allow font smoothing' = $true
	'alternate shell' = $null
	'audiomode' = 2
	'authentication level' = $false
	'auto connect' = $true
	'autoreconnection enabled' = $true
	'bitmapcachepersistenable' = $true
	'compression' = $true
	'connect to console' = $false
	'desktopheight' = $null
	'desktopwidth' = $null
	'disable cursor setting' = $false
	'disable full window drag' = $false
	'disable menu anims' = $true
	'disable themes' = $false
	'disable wallpaper' = $false
	'displayconnectionbar' = $true
	'domain' = $null
	'drivestoredirect' = '*'
	'full address' = $args[0]
	'keyboardhook' = 1
	'maximizeshell' = $false
	'negotiate security layer' = $true
	'prompt for credentials' = $false
	'promptcredentialonce' = $true
	'redirectclipboard' = $true
	'redirectcomports' = $false
	'redirectdrives' = $false
	'redirectposdevices' = $false
	'redirectprinters' = $false
	'redirectsmartcards' = $false
	'remoteapplicationmode' = $false
	'screen mode id' = 1
	'server port' = 3389
	'session bpp' = 32
	'shell working directory' = $null
	'smart sizing' = $true
	'username' = 'agross' # Does not really matter what's in here.
	# http://blogs.msdn.com/ts/archive/2008/09/02/specifying-the-ts-client-start-location-on-the-virtual-desktop.aspx
	'winposstr' = '0,3,2046,129,3086,933'	
	}

Next we check if the local machine has a configuration section in the $workstations hashtable and the script has been called with parameters.

if ($workstations.Keys -inotcontains $Env:ComputerName)
{
	"The local computer is not configured."
	exit
}

if ($args -eq $null -or $args.Length -eq 0)
{
	"No arguments. Supply the RDP server name as the first argument."
	exit
}

Note the Patch-Defaults function and how we use it to add and replace keys in the $defaults hashtable. The replacement values come from $workstations and $servers, with the server settings having precedence. This way, you can configure the connection profile according to the current machine and the server to which the connection will be made. Flexibility!

function Patch-Defaults
{
	param(
		[Hashtable] $defaults = $(Throw "Defaults hashtable is missing"),
		[Hashtable] $patch = $(Throw "Patch hashtable is missing")
		)

	end
	{
		if ($patch -ne $null)
		{
			$patch.GetEnumerator() | ForEach-Object { $defaults[$_.Name] = $_.Value }
		}
	}
}	

Patch-Defaults -Defaults $defaults -Patch $workstations[$Env:ComputerName.ToUpper()]
Patch-Defaults -Defaults $defaults -Patch $servers[$args[0].ToLower()]
$defaults.GetEnumerator() | Sort-Object -Property Name

Now that we have all connection properties in place, we create a temporary connection file from the hashtable key/value pairs and start mstsc.exe with that file.

$tempFile = [System.IO.Path]::GetTempFileName()
$defaults.GetEnumerator() | Sort-Object -Property Name | Set-RDPSetting -Path $tempFile -Name $_ -Value $_

# For debugging purposes.
#"Temporary file: " + $tempFile
#Get-Content $tempFile
#Read-Host

$MstscCommand = $Env:SystemRoot + "\system32\mstsc.exe"
&$MstscCommand $tempFile

Download Open-CustomRDP.ps1

How do we use the script we just created?

You can either create batch files calling the script or use a tool like SlickRun to execute PowerShell with the script.

@powershell.exe -noprofile -command .\Open-CustomRDP.ps1 your.server.example

Another tedious task has been automated!

.NET Bootcamp: Unit Tests

Alexander Groß — Sat, 07 Feb 2009 15:19:54 GMT

In ungefähr einer Woche, am 16.02.2009, findet das zweite .NET Bootcamp der .NET User Group Leipzig statt. Das Thema lautet diesmal Unit Tests und wird neben einer Einführung in das Testen auch Test-Driven Development und Behavior-Driven Development aufgreifen.

Die Organisation des Bootcamps findet wieder nach dem Konzept “Lernen durch Lehren” (LdL) statt. Das heißt, dass jeder Teilnehmer im Vorfeld zwei Fragen als “Hausaufgabe” bekommt und seine Ergebnisse während der Veranstaltung vorstellt. Ich werde die Rolle des Moderators übernehmen, Fragen klären, weitere Aspekte aufzeigen und sicher auch etwas von den Teilnehmern lernen.

Wie unser erster Testballon auf dem Gebiet LdL zum Thema .NET Framework 3.5 ist dieses Bootcamp mit 19 Teilnehmern überbucht. Offenbar kommt LdL gut bei unseren User Group-Mitgliedern an, aus Sicht der Organisation kann ich dies jedenfalls bestätigen!

How To Set Up Secure LDAP Authentication with TeamCity

Alexander Groß — Mon, 02 Feb 2009 16:35:50 GMT

Last week we got a TeamCity Enterprise license at work. After using this great product for about a year we found ourselves running out of available build configurations. (There are 20 in the fully-functional free Professional edition which should be enough to evaluate the product. I recommend giving it a try.) There are a couple of advanced features in the TeamCity Enterprise edition we were looking forward to, for example authentication against a LDAP directory, an Active Directory in our case (AD = LDAP + DNS + a bunch of other stuff).

TeamCity uses LDAP to determine if a user should be able to access the TeamCity web interface. It does that through the LDAP bind operation, asking LDAP to validate the username and password combination entered at the login page.

After hitting the login button TeamCity will connect to the LDAP server, basically taking the text entered in the dialog above passing it to the LDAP bind operation. If the server accepts the username/password combination this means that access is granted. Some things to take into consideration when using LDAP authentication are:

TeamCity does not authenticate against an organizational unit in Active Directory (X.500 address). It just determines if the user (authenticated by username and password) exists anywhere in the directory. You can vote on this ticket to get that fixed.
Because TeamCity does not try to get additional information on the user’s groups memberships it is currently (as of TeamCity 4.0) not possible to automatically assign TeamCity roles to an LDAP user.
If you use the default LDAP configuration settings as shown in the TeamCity documentation, the LDAP connection will be unsecured, making the username and password vulnerable to eavesdropping by anyone who knows how to use packet sniffer.
Specific to Windows: You do not need an Active Directory infrastructure with a Domain Controller in place. Windows also supports Active Directory Application Mode (ADAM) on Windows Server 2003, renamed to Active Directory Lightweight Directory Services (AD LDS) in Windows Server 2008.

Given the things above, what are your options to secure the LDAP connection? You could change the authentication scheme to not use "simple” LDAP authentication, but choose from a variety of SASL options. I didn’t go down that road, because when I started to configure LDAP for TeamCity I basically knew nothing about neither LDAP nor SASL.

Using LDAPS (LDAP over SSL), which is also supported by Windows servers running some AD mode, appeared to be a viable option to enforce secure communication between TeamCity and the LDAP server.

Installing The LDAP Server

Setting Up LDAPS with Active Directory (Domain Controller mode)

There’s not much set up needed with this configuration. When you install Active Directory in Domain Controller mode you should also get an instance of Certificate Services that will create a self-signed certificate for your domain controller. This certificate will be used for LDAPS connections to the directory server, which is typically the domain controller.

As an aside, I’m not expert in setting up AD, please refer to your network administrator.

Setting Up LDAPS with Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS)

As noted above, this setup is supported on any Windows Server and does not require the full-blown “Domain Controller” version of Active Directory. ADAM/LDS supports user authentication either against the ADAM/LDS instance (users created in the directory) or a against local Windows accounts (through a user proxy, see below)

Installing ADAM or AD LDS

Installing ADAM/LDS differs depending on which Windows Server version you have. I did it with Windows Server 2003:

Navigate to the Control Panel and open up the Software control panel applet, appwiz.cpl
Click “Add or remove Windows features”
Select Active Directory Services, click on the Details… button and select Active Directory Application Mode. Close the window.
Scroll down to Certificate Services entry and check it. (IIS will also be installed as part of Certificate Services to support web registrations.)
Click Next.
On the next dialog, you will be asked what type of Root Certificate Authority (CA) to install. Select “stand-alone“ CA and also check the “Create key pair” option.
The next dialogs allows to select different options for the Root CA keys and the CA itself. I went with the defaults.
Certificate Services and ADAM will be installed.
Under Programs in the Start Menu there will be a new folder named “ADAM”. Click on the “Create ADAM instance” link.
The ADAM wizard pops up, click Next.
Choose “Create new unique instance” and click Next.
Enter the name of the ADAM instance. I chose “TeamCity”, because we’re using ADAM to authenticate TeamCity users. Click Next.
Write down the ports that are presented in the next step. The default LDAP port is 389, and the port for LDAPS is 636. Click Next.
In the next step, choose to create a directory partition. Mine is called CN=TeamCity, DC=test, DC=local. Click Next until you reach the “Import LDIF files” dialog.
Import at least the MS-User.ldf and MS-UserProxy.ldf schemas to enable the creation of local directory users and user proxies for Windows accounts.
Click Next and wait for ADAM to be configured.

Setting Up ADAM or AD LDS to Accept SSL Connections

There are two good tutorials that I used to enable SSL on ADAM, so I won’t reiterate them here. I suppose the process of enabling SSL on LDS is similar.

User Management

You now have a LDAP server running that will serve requests for the LDAP and LDAPS protocols. Next, you would have to add users to the directory, which could either be

Local directory users: user and password stored in the directory; used with “simple” bindings, or
Windows users: users password stored by the local Windows account manager or in a full-blown AD domain; used with “proxied” bindings (from the outside, these also appear as “simple” bindings).

Windows users require a user proxy in the directory, linking the proxy to a Windows account SID. The link between the proxy and the Windows account is established though the Windows account’s Security Identifier (SID) which must be supplied when the proxy is created. Setting up user proxies is a bit complicated and well worth another post.

Please note that by default authenticating users through their respective proxies (proxied binding) requires a secure connection, unless you explicitly disable it. Unfortunately the attribute to change is not given in the linked article: it is msDS-Other-Settings. You can either require security for simple or proxied bindings by setting RequireSecureProxyBind (defaults to 1) and RequireSecureSimpleBind (defaults to 0) to either 0 or 1.

The net result of the default ADAM configuration (RequireSecureProxyBind=1) together with the default TeamCity configuration (ldap://some-server, which is unsecured) is that authentication requests for user proxies will always fail.

Setting Up TeamCity

Setting Up TeamCity to Use The LDAP Server

The easiest way is to start with the default TeamCity configuration in <TeamCity data directory>/config/ldap-config.properties:

java.naming.referral=follow
java.naming.provider.url=ldap://ldap.test.local:389
java.naming.security.authentication=simple

Unless you want to require your users to enter their login in the DOMAIN\username format I recommend adding the loginFilter property:

java.naming.referral=follow
java.naming.provider.url=ldap://ldap.test.local:389
java.naming.security.authentication=simple
loginFilter=.+

Now we need to set up the correct "user name" string to present it to the LDAP server. This string is created from the text entered in the "Username" text box on the login screen ( $login$ ) and differs depending on whether you use LDAP with AD or ADAM/LDS:

java.naming.referral=follow
java.naming.provider.url=ldap://ldap.test.local:389
java.naming.security.authentication=simple
loginFilter=.+

# AD - authenticate against the TEST domain
formatDN=TEST\\$login$

# ADAM and presumably AD LDS - users will have to reside in the CN=Users,CN=TeamCity,DC=test,DC=local container
formatDN=CN=$login$,CN=Users,CN=TeamCity,DC=test,DC=local

Setting Up LDAPS Security

Enabling LDAPS is pretty easy from a TeamCity perspective. You just have to change line 2 of the configuration above to use the secure LDAP protocol:

java.naming.referral=follow
java.naming.provider.url=ldaps://ldap.test.local:636
java.naming.security.authentication=simple
loginFilter=.+
formatDN=<some value>

Changing the protocol to use ldaps:// will not instantly work and users would not be authenticated. Why?

Trusting The Certificate

What does LDAPS mean from a Java perspective? If you work on a domain (AD) or use ADAM/LDS with SSL you are very likely to work with self-signed SSL certificates. Such certificates are inherently untrusted as they are not issued by some trusted party (and this trusted party will charge money). Nevertheless they are perfectly okay for your environment.

When TeamCity establishes the SSL connection to your LDAP server, it is first presented with that untrusted certificate – and bails. Here’s a snippet from the TeamCity log files:

[2009-01-27 16:14:39,864]  ERROR - Side.impl.auth.LDAPLoginModule - 
 
javax.naming.CommunicationException: simple bind failed: ldap.test.local:636
[Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

To establish LDAPS connections successfully, you have to tell Java to trust your LDAP server’s certificate. Andreas Sterbenz has created a little Java utility called InstallCert that helps in that regard. Unfortunately you will have to compile it yourself against the Java 1.5 runtime, so here’s a compiled version that works with TeamCity.

Place the files from the ZIP in your <TeamCity root>\jre\bin directory. Open a command prompt and enter

java InstallCert ldap.test.local:636

Following the procedure described in Andreas' post, the utility will create a file called jssecacerts in the same directory. Overwrite <TeamCity root>\jre\lib\security\cacerts with that file.

After re-starting the TeamCity web server, it is now able to establish secured connections to the LDAP server. The user names and passwords transmitted over these connections will not be visible to outsiders.

Wrapping It Up

In this article I’ve shown you how to enable and secure TeamCity’s LDAP authentication in any Windows environment, be it an Active Directory domain or a couple of stand-alone Windows Servers. For both scenarios user management is centralized, either though the AD console or LDAP console in combination with the Windows user management console.

Figuring out all that has taken a considerable amount of time for me and hopefully saves you a couple of minutes that you can spend outside in the sun.

Setting up SourceGear DiffMerge with Git

Alexander Groß — Wed, 28 Jan 2009 20:18:58 GMT

For about six month I’m using Git as my preferred Source Control Management system. That is, while my colleagues at work still work with Subversion and TortoiseSVN, I am leveraging the powers of Git behind the scenes. That is, I work on local (Git) feature branches that I commit to our SVN trunk every once in a while, typically after I finished working on a feature.

If you want to get started with Git, I recommend watching the GitCasts and try one of the Windows distributions, msysgit or Cygwin. (I switched to Cygwin after the msysgit team dropped SVN integration in their 1.6 release.)

Git heavily relies on the command line, and UI tools like gitk and TortoiseGit are not quite there yet. Using a CLI might be something a lot of Windows developers do not look forward to, but you still can configure support for some UI tools. For example, file diffs and merges can be customized to work with any tool (UI and CLI-based). I use SourceGear DiffMerge (free) as my primary diff and merge tool. It’s far better that what comes with TortoiseSVN or Git itself (again CLI-based).

I could only find sparse documentation on how to make DiffMerge work with Git, so I dove into the world of Shell programming and created a couple of simple scripts. Here is what I came up with.

diffmerge-diff.sh

#!/bin/sh

path="$(cygpath $1)"
old="$(cygpath --mixed --absolute "$2")"
new="$(cygpath --mixed --absolute "$5")"

#echo -e "path\n$path"
#echo -e "old\n$old"
#echo -e "new\n$new"

"/cygdrive/C/Tools/DiffMerge/diffmerge.exe" "$old" "$new" --title1="Old" --title2="New $path"

diffmerge-merge.sh

#!/bin/sh

localPath="$(cygpath --mixed --absolute "$2")"
basePath="$(cygpath --mixed --absolute "$1")"
remotePath="$(cygpath --mixed --absolute "$3")"
resultPath="$(cygpath --mixed --absolute "$4")"

if [ ! -f $basePath ]
then
    basePath="$(cygpath --mixed --absolute ~/diffmerge-empty)"
fi

#echo -ne "local\n$localPath\n"
#echo -ne "base\n$basePath\n"
#echo -ne "remote\n$remotePath\n"
#echo -ne "result\n$resultPath\n"

"/cygdrive/C/Tools/DiffMerge/diffmerge.exe" --merge --result="$resultPath" "$localPath" "$basePath" "$remotePath" --title1="Mine" --title2="Merged: $4" --title3="Theirs"

Setting up Git

Put the files above in your home directory, either C:\Cygwin\home\<username> (Cygwin) or C:\Users\<username> (msysgit). Make sure the line endings are LF-only (UNIX style) and the file is saved without the UTF byte-order mark (BOM).
Create an empty file named diffmerge-empty in the same directory.
Modify the scripts to point to the correct location of DiffMerge (see the last lines). Some more modifications will be needed if you’re from the msysgit crowd, as the cygpath utility is not available there.

Open a Git CLI and enter the following commands:

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.cmd "~/diffmerge-merge.sh \"\$BASE\" \"\$LOCAL\" \"\$REMOTE\" \"\$MERGED\""
git config --global mergetool.diffmerge.trustExitCode false 
git config --global diff.external "C:/Cygwin/home/<username>/diffmerge-diff.sh"

This should add the following lines to your .gitconfig:

[merge]
    tool = diffmerge
[mergetool "diffmerge"]
    cmd = ~/diffmerge-merge.sh \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"
    trustExitCode = false
[diff]
    external = C:/Cygwin/home/<username>/diffmerge-diff.sh

Using DiffMerge

Using DiffMerge is pretty easy, the normal git diff and git mergetool commands work as usual, but will now spawn DiffMerge instead of vi (which is the default). If anything does not work as expected, uncomment the #echo lines and use a tool like Process Monitor and Process Explorer to see where things go wrong.

Happy diffing!

Rezept: Zwiebelmarmelade

Alexander Groß — Mon, 05 Jan 2009 14:14:18 GMT

2 rote Zwiebeln
1 EL Butter
1 EL Honig
Balsamico
Apfel-Kirsch-Saft o. ä.
1-2 EL Zitronensaft
Salz, Pfeffer

Zwiebeln schälen und in feine Ringe schneiden. Die Butter in einem Topf zergehen lassen und die Zwiebeln glasig dünsten. 1 EL Honig hinzugeben und leicht karamelisieren. 3 EL Balsamico angießen und einreduzieren. Anschließend wenig Apfel-Kirsch-Saft zugießen und einkochen lassen. Angießen und einkochen wiederholen bis die Zwiebeln weich gekocht sind (das dauert ca. 30 Minuten). Mit Zitronensaft, Salz und Pfeffer abschmecken.

Die Zwiebelmarmelade passt aufgrund ihrer süßlichen Note gut zu Speisen mit würzigem Käse, z. B. Käsefondue oder Ziegenkäse.

Cambodian Round-Up

Alexander Groß — Wed, 03 Dec 2008 04:47:50 GMT

Lange nichts von uns gehört? Wir waren auf der Insel, ohne Strom und fließend Wasser. Doch von vorn:

Phnom Penh

Wir haben unseren Tag in Phnom Penh genutzt um die Sehenswürdigkeiten der Stadt anzusehen. Dazu gehörte neben der Silbernen Pagode (als Teil des Königspalastes) auch ein tragisches Denkmal der jüngeren kambodschanischen Geschichte: Das Gefängnis "S-21" in dem vor weniger als 30 Jahren ca. 10000 Menschen gefangen gehalten, verhört, gefoltert und getötet wurden. Der Trakt des S-21, ein Areal von 600 x 400 m wurde vor der Machtergreifung der Roten Khmer als Schule genutzt und ist heute größtenteils so erhalten wie es nach der Befreiung von Phnom Penh vorgefunden wurde. In den Einzelhaftzellen stehen immer noch die gleichen Betten auf denen die Gefangenen, also Intellektuelle, Lehrer und Brillenträger angekettet ihr jämmerliches Dasein fristen mussten. Im Zusammenhang mit der Geschichte der empfielt sich die Lektüre des Buchs "First They Killed My Father" von Luong Ung. Robert besitzt ein deutsches Exemplar, Gunnar die englische Ausgabe.

Außerdem haben wir den Zusammenfluss von Tonle Sap und Mekong besucht und haben die Stadt zu Fuß erkundet. Phom Penh vermittelt dabei das Gefühl einer langsam wachsenden Großstadt; die meisten Straßen sind eher klein, Hochhäuser über ~16 Stockwerke gibt es überhaupt nicht.

Rabbit Island

Am nächsten Tag haben wir uns auf Empfehlung von Rita nach Süden auf eine kleine Insel namens Koh Tonsay begeben. Das auch Rabbit Island genannte Fleckchen Erde liegt kurz vor der Vietnamesischen Grenze, was auch die Frage des Grenzbeamten am Pier erklärt: "Which nationality?" – "German". — Passkontrolle kann so einfach sein.

Unsere vier Tage auf der Insel waren geprägt von viel Entspannung, Lektüre, Feuer am Strand, Feierabendbierchen und Seafood. Bewohnt haben wir zusammen mit sehr wenigen anderen Backpackern eine der Strohhütten an einem der drei Strände der Insel. Tatsächlich ist nur "unser" Strand touristisch erschlossen, d. h. es gibt abends für 2, 3 Stunden Strom aus dem Dieselgenerator und eine Toilette. Die anderen Strände sind im Besitzt der einheimischen Insulaner, die Seetang anbauen. Die Inselumrundung haben wir entspannt in 3 Stunden geschafft.

Beobachtungen

Während der Zeit in Kambodscha sind mir einige Dinge aufgefallen, die aus meiner Sicht Erwähnung verdienen:

In unregelmäßigen Abständen befinden sich Werbetafeln für die großen Parteien (FUNCIPEC, Cambodian People Party) direkt an der Straße. Ein Einheimischer erklärte mir, dass die Leute Werbung machen, ohne dass die dafür Entlohnung erhielten, sondern das aus Überzeugung tun und um Nachbarn für ihre favorisierte Partei zu gewinnen. Dabei kann es sein, dass Nachbarn rivalisierende Parteien vertreten, was aber kein Konflikt darstellt.
Wer sich nicht von den kambodschanischen Bauern unterscheiden will, baut am besten Reis an. Die Reisernte hat gerade begonnen und verwandelt die vormals sattgrünen Felder in braune Steppe. Die grasenden Wasserbüffel freut es. Der Reis wird nach der Ernte noch ungeschält getrocknet, was auch gern am Straßenrand passiert. Vermutlich ist der heiße Asphalt in Kombination mit dem Straßenstaub hilfreich :)
Tiere werden prinzipiell freilaufend gehalten, ich habe keine Ställe gesehen.
In Kamdoscha werden zwei Währungen akzeptiert: Gezahlt wird meist in Dollar, Wechselgeld erhält man in Riel. 1 Dollar entsprechen 4000 Riel. Aus eigener Erfahrung kann ich sagen, dass die gemischten Währungen die Bezahlung von Rechnungen nicht einfacher machen.
Frisches Obst wird viel seltener verkauft als in Thailand. Auf der Insel gab es z. B. nur Kokosnuss, zu Lande auch mal eine Mango. Früchtewägen wie aus Thailand bekannt sind mir nicht zu Augen gekommen. Auf dem Marktplatz werden Waren zu ebener Erde angeboten, was oft keinen hygienischen Eindruck vermittelt. Fliegen umschwirren das Fleisch auf dem Marktplatz.
Wir haben zwei leckere Gerichte kennengelernt: Lok Lak, eine Art Rindfleischgeschnetzeltes, serviert zusammen mit einer leckeren Sauce aus schwarzem Pfeffer, Salz und Limettensaft. Das andere gericht heißt Amok und wird mit Chicken, Shrimps oder Beef serviert und ähnelt einem Curry. Außerdem gibt es viel internationale Küche.
Im Land und auf der Insel wehte, jahreszeitlich bedingt, ein stetiger Wind, den wir so nicht aus Thailand kennen. Das Klima war deshalb etwas angenehmer, vergleichbar mit europäischem Sommer. Natürlich hält das die Busfahrer nicht davon ab die Klimaanlage auf 18°C zu drehen, und das trotz mehrmaligem Bittens auch nicht zu ändern.

Zurück in Thailand

Gestern früh um 7 galt es den Kutter Richtung Festland zu nehmen und die Reise zurück nach Thailand anzutreten. Zunächst sind wir mit dem Tuk Tuk in den kleinen Küstenort Kampot gebracht worden, um dort am hektischen Busterminal in ein größeres Gefährt verfrachtet zu werden. In Kampot haben sich die Wege unserer Viererreisegruppe getrennt: Jan und Robert sind nach Phnom Penh abgereist von wo sie hoffentlich mit dem Flieger nach Kuala Lumpur weiterreisen können, um ihren umgebuchten Emirates-Flug zu bekommen. Marci und ich sind mit dem Minibus über eine gut ausgebaute aber wenig befahrende Straße in Richtung Trat (Thailand) gefahren, wo wir gerade im Internetcafé sitze. Übrigens erstaunlich, dass 17 Personen (wir als einzige Ausländer) in einen für vielleicht zwölf Mann ausgelegten Minibus Platz finden. Auf unserer Fahrt haben wir sogar ein Gefährt mit schätzungsweise 22 Personen überholt. Leere Fahrzeuge gab es nicht.

Die Pläne für die verbleibenden Tage sehen wie folgt aus: In ein paar Stunden nehmen wir einen Bus in Richtung Khao Yai National Park um drei oder vier Tage in der Natur zu verbringen: Khao Yai beherbergt u. a. Elefanten und Tiger im größten verbliebenen Stück natürlichen Regenwald in Asien. Danach geht es weiter nach Bangkok um unsere dort gelagerten Sachen zu holen und mit Anthony, Rita und Agnes essen zu gehen. Da nach unseren letzten Informationen die Flüge von Emirates erst am 13.12.2008 wieder normal verkehren, nehmen wir anschließend den Zug nach Kuala Lumpur durch das südliche Thailand.

Auf dem Weg nach Phnom Penh

Alexander Groß — Thu, 27 Nov 2008 03:39:36 GMT

Oder: Peng Peng, unser Kosename der Stadt.

Eine weitere Busreise und wir sind in Phnom Penh eingetroffen. Die Fahrt ging vorbei an schier endlos wirkenden Reisfeldern (sowohl als Schlammfeld, Setzlinge und in reifendem Zustand) diesmal sogar auf einer Asphaltstraße. Das "bisschen" Asphalt macht den Unterschied, plötzlich müssen die Menschen nicht mehr im roten Dreck leben und können vergleichsweise mehr Hygiene genießen, auch wenn sie meist in Holzhütten auf Stelzen oder in einfachen Verschlägen wohnen. Auch Schulen gibt es einige, erkennbar an den Schulkindern die nachmittags in weißen Blusen und Hemden den Heimweg auf dem Rad antreten.

Die Ackerflächen werden etwas diversifizierter genutzt, so wird nicht nur Reis angebaut, sondern auch Fischzucht betrieben und Gemüse angepflanzt. Tiere wie Hühner, Hunde, Rinder, klein erscheinende Katzen und (wenige) Pferde scheinen sich selbst zu versorgen, sie laufen frei herum und bedienen sich auch schon mal am Reisfeld, wenn es nicht brusthoch mit Wasser gefüllt ist. Durch die fruchtbaren Schlämme des Tonle Sap kann oft sogar zwei mal pro Jahr geerntet werden.

Das Fortbewegungsmittel Nummer 1 auf dem Land und in der Stadt ist nach wie vor das Moped das gern unter 30 km/h gefahren wird. Der Busfahrer hat sich um Programm bemüht, so wurde fast jeder Mopedfahrer mit mehrfachem Hupen "begrüßt". (Hupen wird als Signalzeichen genutzt: Achtung, hier komme ich.) Während der Fahrt gab es zwei DVDs mit lokalen Programm zu genießen: Zunächst Karaoke-Schmalz-Videos eines kambodschanischen Jugendstars, anschließend ein 3-Stunden-Epos über den Werdegang eines kleinen Jungen mit Quietschstimme zum Lehrer einer geheimnisvollen Kunst (mehr habe ich nicht verstanden). Es war noch etwas Zeit bis zur Ankunft, und so wurde der Popstar ein zweites Mal eingelegt.

Unterwegs wurden ein paar Stops an Busstationen eingelegt, die wir selbst wahrscheinlich nie als solche identifiziert hätten. So diente einmal ein selbstgemaltes Busschild als Haltestellenzeichen, ein ander Mal saß einfach jemand da, der sich durch Gestikulieren um das Anhalten den Busses kümmerte.Bei diesen Stops wurden und Snacks dargeboten, u.a. auch gegrillte handtellergroße Spinnen, von denen wir aber noch nicht probiert haben.

Siem Reap und Angkor Wat

Alexander Groß — Tue, 25 Nov 2008 16:20:31 GMT

Die Reise von Trat nach Siem Reap, der Stadt direkt vor der riesigen Khmer-Tempelanlage Angkor Wat, Weltkulturerbe und in mehreren Etappen um das Jahr 1000 erbaut, lief recht angenehm per Privat-Jeep. Bis zur Grenze. An der Grenze angekommen haben uns die freundlichen Thai-"Schleußer" den Grenzübertritt mehrfach erklärt und uns in kleinen Gruppen zu 4 Personen über die Grenze geführt. Angekommen auf der kabodschanischen Seite fiel zunächst auf, dass bei Jan ein Thai-Stempel im Pass fehlte. Also schnell zurück und den blauen Abdruck nachgeholt. Zwischen den Grenzen, im Niemandsland, wurde eine stattliche Anzahl von Kasinos erbaut, die auch gern von Thais genutzt wird (Glücksspiel ist in Thailand verboten).

In Kamboscha fiel uns sofort die miese Qualität der, nennen wir es mal so, Straßen ins Auge. Diese bestehen im wesentlichen aus Schlaglöchern, Staub und Müll. Auf einer solchen ging es im Anschluss 6 Stunden im Bus nach Siem Reap. Das noch in Thailand als Air-Con Bus angepriesene Gefährt entpuppte sich als lokaler Bus, mit "Fenster-Air-Con". Die Straße wird zwar an einigen Stellen gebaut, den Großteil ging es aber über eine holprige rote Staubpiste, die sich beim Regen in entsprechenden Matsch verwandelt hat. Wenige Meter von der Straße wohnen Menschen unter der permanenten Staubwolke in ihren einfachen Verschlägen und bepflanzen die weiten Reisfelder links und rechts der Straße. Trotz aller Widrigkeiten war diese Reise ein Heidenspaß, zumal wir uns samt Gepäck in der letzten Sitzreihe platziert haben.

In Siem Reap sind wir ins Guest House "Hilton" eingecheckt (nicht zu verwechseln mit der gleichnamigen Hotelkette :). Es liegt zwar etwas außerhalb der Kneipenmeile Psah Char, bietet aber einen kostelosen Tuk Tuk-Shuttleservice in die Innenstadt. Wir haben auch den Guide John an de Hand bekommen der recht gut Englisch spricht und uns ein paar Dinge gezeigt hat. Siem Reap selbst ist keine schöne Stadt, auf mich wirkt sie vielmehr als Touristenschleuße. Siem Reap - Angkor Wat anschauen - und schnell wieder weg. So werden wir es auch halten, nach einem Tag Tempelgucken (zusammen mit Unmengen vornehmlich japanischer Touristen) haben wir genug und fahren morgen weiter nach Phnom Penh. Entgegen unserer Pläne haben wir uns gegen das Boot auf dem Tonle Sap und für den Bus entschieden. Das Speed Boat kostet mit US$35 sechs mal so viel wie der Bus und man sieht nicht so viel vom Land und den Leuten.

The Right Stuff

WinDbg Commands

How To Set Up A Git Server On Windows Using Cygwin And Gitolite

Contents

What You Need

Installing Cygwin

Connecting Cygwin to Windows Security

Setting Up the SSH Server

Enabling SSH Client Access

Verifying SSH Password Access

Creating Your SSH Identity

Making the SSH Server Aware of Your SSH Identity

Installing Gitolite

Wrapping Up

Rezept: Eintopf

Machine.Specifications Templates For ReSharper

Legend

File Template

Live Templates (a.k.a. Snippets)

Surround Templates

Download

How We Practice Continuous Integration And Deployment With MSDeploy

Deployment Over Network Shares Or SSH

MSDeploy

The Deployment Workflow

Rake And Configatron

What I Haven’t Talked About

Wrapping Up

Rake, YAML and Inherited Build Configuration

YAML

YAML’s “Inheritance”

Custom Inheritance

Visual Studio Tip: Setting Indent Width and Tabs/Spaces Quickly Using Macros

Using the Microsoft Solver Foundation Add-In for Excel

Rezept: Victoriaseebarsch auf dem Gemüsebett

Rewriting Git History: Relocating Subversion URLs

Migrating SharePoint Content Databases To A New Farm While Keeping Security Settings

ChkDskAll ‒ ChkDsk For All Drives

Creating Remote Desktop Connection Files On The Fly With PowerShell

.NET Bootcamp: Unit Tests

How To Set Up Secure LDAP Authentication with TeamCity

Installing The LDAP Server

Setting Up LDAPS with Active Directory (Domain Controller mode)

Setting Up LDAPS with Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS)

Installing ADAM or AD LDS

Setting Up ADAM or AD LDS to Accept SSL Connections

User Management

Setting Up TeamCity

Setting Up TeamCity to Use The LDAP Server

Setting Up LDAPS Security

Trusting The Certificate

Wrapping It Up

Setting up SourceGear DiffMerge with Git

diffmerge-diff.sh

diffmerge-merge.sh

Setting up Git

Using DiffMerge

Rezept: Zwiebelmarmelade

Cambodian Round-Up

Phnom Penh

Rabbit Island

Beobachtungen

Zurück in Thailand

Auf dem Weg nach Phnom Penh

Siem Reap und Angkor Wat