Rob Golding

For a while now, I’ve been using Subversion to keep track of personal projects and coursework at university. SVN is installed on the UNIX servers as Computer Science, so it’s a relatively trivial process to get up and running with a repository when I start a new assignment.

Recently though, I’ve been looking in to Mercurial as a more modern alternative. Some things about Subversion are really starting to annoy me, like the inability to ignore files on a repository-wide level easily (I work with Python all the time, so .pyc files can really get on my nerves!). Mercurial seems slicker, and I’m interested in the concept of DVCS, as opposed to the classic client-server way of thinking.

However, Mercurial is not installed on the (rather ancient, now) Solaris servers at university. I really admire the job that the sysadmins do, so I am in no way condemning them for it not being installed. Instead, I set out to get it compiled and working myself.

Installing it on the servers, it seemed, was the easy part. I followed the installation instructions (making sure to include the LD_LIBRARY_PATH variable) and all was well.

Cloning from the server, however, wasn’t so easy. The problem lies in the fact that Mercurial is now installed for me, and me alone. The hg binary lives in my home directory, not on the server’s main path (i.e. the /usr/bin/ directory). Therefore, I needed to tell the client exactly what command to run on the server. If anyone else is having the same trouble, the command that I finally came up with looks like this:

hg –config ui.remotecmd=”LD_LIBRARY_PATH=/usr/sfw/lib PYTHONPATH=~/lib/python ~/bin/hg”

I then aliased this command to hgtuck to save my sanity (the server is named tuck, after Friar Tuck in the Robin Hood legends), and I now have a perfectly working Mercurial install!

If anyone else is looking to do something similar, then I hope this little tip saves you some time!

Thanks to the MSDNAA program, I’m able to try out the latest version of Windows Server in the lab. I opted to migrate my domain accross to a new machine, instead of performing an in-place upgrade. Personally I feel this is a much safer bet, and tend to migrate domain controllers whenever I’m doing something pretty major to a DC.

So far everything looks good, I’ve upped the forest and domain functional level to Server 2008, so I can now take advantage of some of the new features – though I’m yet to find out what they all are! The best thing so far (by a mile I’d like to add) is the addition of Group Policy Preferences. Although it’s annoying having to install the Client-Side Extensions on every machine in the domain (that is if WSUS isn’t in use), the gains faw outweigh this bit of pain. I only wish an MSI could have been released, so that it could easily be pushed out using the existing Group Policy infrastructure. Never mind, eh?

Anyway, on with the good! The new GP Preferences allow an administrator to define, amongst others, drive maps for client machines, printer connections and power options. As you may be thinking, this just about does away with the need for logon scripts! Most, if not all of the common tasks that are performed with logon scripts can now be done from a group policy object.

There are also a lot of changes to the way Active Directory works. In Server 2008, Active Directory Domain Services can be installed on a machine, without actually making it a DC. What this means is that a standard server build can be ’sysprepped’ with the files required for promoting the server to a DC, without actually doing the promotion. Also, Read-Only Domain Controllers (RODCs) have been introduced as a new feature. Essentially, an RODC just caches queries from a normal DC, usually located at another site – apparently allowing for faster logon times at remote sites with slow links. After discussion with a colleague, however, the benefits of such a system are maybe not quite as advertised. For example, only one RODC can be installed per site – so larger sites can’t benefit from the redundancy and load balancing offered by multiple DCs, if RODCs are used. Also, the much-touted security advantages of using an RODC aren’t as they seem either, as the database can be just as easily written to, just through another “normal” DC.

More on this later!