Recently in Windows Category

IIS 7 is Microsoft's latest web server, if such a complex and comprehensive package can be reduced to two words.  I've been working with IIS for the first time, and it sure as heck isn't Apache.

The ClearCanvas PACS installation has been about getting three items installed and communicating - ClearCanvas itself, IIS, and SQL Server. I found a very good resource for debugging IIS 7 errors: Mark Volodarsky's Troubleshoot IIS Errors Like A Pro.    

I followed his instructions for turning on Failed Request Tracing Rules.  This does largely what it says, building a log file of failed requests.  This in turn led me to another error 500.19 Internal Server Error: "This configuration section cannot be used at this path" in my web.config file located within the ClearCanvas Server web directory.

Pressing on...I'm out of my depth here.  I followed these instructions regarding editing my applicationHost.config file located in Windows\system32\inetsrv.  Hey I've come this far, why not start messing with system files I don't understand.  I turned on overrideModeDefault to "allow" for several modules.  While I was at it, I went back to the IIS settings in the Windows Features, and checked pretty much every feature I could find for IIS.  I'm going to need about a terabyte of RAM to run all this.

I'm not sure if I've made progress.  Now when I try to access the local CC Server web site I get a Server Error stating, amongst other things, "WRN: Assembly binding logging is turned OFF.  To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.".   Into the Registry Editor I go, what the heck.  I discover there is no key called Fusion!EnableLog...and I'm out of ideas.  I'm not going to start hacking the registry blind.


 

I've been working with Interix (Windows Subsystem for Unix Applications) instead of Cygwin for about a month now, to provide the Unix environment I want/need on my Windows systems.  Overall, I like it.  I like the idea of it being part of the OS instead of an application.  I like how it can use Active Directory for accounts, instead of having to generate /etc/passwd files as Cygwin does.  I like how fast it is: depending on what I'm doing, anything up to 10 times faster and 10 times less memory consumption than Cygwin.  I like how it has native Unix file sharing, and processes so monitoring tools like top still work.

I'm still working on some of the things that haven't worked smoothly.  I've only been using it for a month versus five years or more with Cygwin, so I wouldn't call them dislikes yet.  I'm installing release 6.0 of SUA/Interix, which runs on Windows Server 2003 R2 and Server 2008, and the Enterprise and Ultimate versions of Windows Vista.  I'm installing it on my workstation which has a dual core Xeon processor, and a number of compute nodes that have dual quad-core Xeons.

First, the system tools (like ls) are the straight BSD kind.  Which is fine, but I've become used to the GNU file utilities, such as the -B switch to ls to suppress Emacs backup files~, or the -m switch for MB for du.  I can always download the source and build them myself - gcc is supplied with the installation - but there have been some issues and this leads me to the bigger issue: 64 bit support.

I'm running an all 64-bit environment.  I regularly work with files up to 50 GB and most of my machines have 12 GB of RAM.  So 64 bit is a must.  It's been tricky to get full 64 bit Interix installed and running, and in fact I haven't managed it yet.  But I read that it's supported, so I believe it.  The problem is that system tools tend to be 32 bit so they give random results for large files - du reporting that a 5 GB file is 1 GB, say.  I've found that if I install the bundle of tools from Interix, I get the 32-bit variety and from there it's hard to install the 64-bit variety.  So after several installs and uninstalls I've settled on this sequence on my workstation runnign Vista Enterprise:
- Turn on 'Subsystem for Unix Applications' in 'Programs and Features' in the Control Panel.
- Download and install the Microsoft 'Utilities and SDK for Subsystem for Unix-based Applications'.  This is a menu option after you've turned on SUA.
- Next, I don't install the tools from the Interix site.  If you follow their instructions, this is the next step.  However I've found these either don't test or don't detect my 64-bit hardware, so I get the 32-bit utilities.
- Now, I download the 'Bootstrap Installer' from Interix and run it.  This just installs the package handling utilities (pkg_add, pkg_upgrade etc) and a few small Unix programs to allow the packages to be installed.

The problem now is that packages have to be installed individually, with a special switch to specify that only the 64-bit versions are to be installed.  This goes like this: <pkg_upgrade -M strict64 -L packagename.  It's a bit clunky, as if there isn't a 64-bit version of the given package, the command just fails instead of installing the 32-bit version which would be better than nothing.  So you have to do it again without the -M switch.

That's where I stand now.  If this all works I'll script up the installation so I can deploy it on any number of machines.  For now I'm taking it slowly.

I've been using Cygwin for years.  Mostly, it's to give me a consistent work environment since most of my work is on Unix machines.  Partly, I suppose, it's to put off learning how to do the same things I can do on the Unix command line - programming tools, text processing, sysadmin.  It's worked well for me and I've developed a standard setup of tools and configurations that I'm familiar with.  This gets installed on every Windows machine I work on, using a little script.  With over 50 machines to keep running (mostly they're single-user compute nodes), this makes life easier.

I like the Cygwin tools for adding new features.  You can do this through the gui or using the apt-cyg utility to do it from the command line or a script.  Once Cygwin is in, I set up Perl and the various libraries I use using Cpan.  This can be automated too.

Cygwin is great but I've found a few things that remind you you're not running a Unix machine, but a program on a Windows machine.  File protection can get messed up, and I have problems sometimes with corrupt files, files that can't be deleted, corrupt names, and other strangeness.  User admin is through local files so it's hard to deploy a number of machines.  File sharing uses Windows protocols, more inconsistencies.  There are others, like these, they're mostly related to using a number of machines in a mixed Unix/Windows network.

So recently I tried switching to Interix.  It's a native Windows product that is supported by Microsoft but developed independently.  Since it's integrated into the Windows kernel it can implement file and user protection using more information than is available to the Cygwin application.  It's pretty easy to set up standalone installation but of course I immediately wanted to add Unix file sharing and SSH login.  There's a package manager that makes this pretty simple, and you can install bundles of packages to make life easy.  So far, I like it.