Contact

Alexander Groß
  • Send mail to the author(s) E-mail
  • del.icio.us
  • Skype
  • twitter
Feed Icon

Tags

Open Source Projects

Archives

Blogs of friends

Now playing [?]

  1. Sascha Funke – Chemin des Figons
  2. Sascha Funke – Lotre (Mehr fleisch)
  3. Sascha Funke – Double Checked
  4. Sascha Funke – Summer Rain
  5. Sascha Funke – Take a Chance With Me
Audioscrobbler/Last.fm

ClustrMap

Rezept: Victoriaseebarsch auf dem Gemüsebett

Posted in Recipes (German) at Tuesday, June 30, 2009 9:32 PM W. Europe Daylight Time
  • 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

Posted in .NET | Git at Thursday, June 25, 2009 8:59 PM W. Europe Daylight Time

Git LogoToday 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

Posted in .NET | SharePoint | SQL Server at Saturday, April 25, 2009 4:40 PM W. Europe Daylight Time

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

Posted in .NET | Tools and Software | Windows at Saturday, February 14, 2009 4:41 PM W. Europe Standard Time

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

  1. Open an elevated command prompt or log in as an administrator,
  2. Run chkdsk <Drive>: /f,
  3. 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.

Chkdsk UI

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.

ChkDskAll In Action

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>

Creating Remote Desktop Connection Files On The Fly With PowerShell

Posted in .NET | PowerShell at Friday, February 13, 2009 6:28 PM W. Europe Standard Time

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.

Desktops

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

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!