Nynaeve

After wasting about 4 hours on this subject, I think it has deserved the right to be spoken about.

 Since I decided to finally give this whole blogging thing a try, I went looking for an appropriate set of blogging software to use.  My first instinct was to try Community Server with SQL Server 2005 Express Edition.  Hey, it works for Microsoft (MSDN Blogs is powered by Community Server), so it should work for me, right?  And to make things even better, it’s a native Windows solution (I was planning on the deploying the blog on a Windows box), not a Unix port (which in my experience tend to be half-hearted and generally low quality, as far as applications go).

 Boy, was I wrong.

 After waiting about half an hour (I think) for SQL Server 2005 to install on my interim hosting box (which, although it isn’t the fastest box in the world, should really install the “lite” edition of SQL Server a little bit faster than that, I think), I set to work on setting up my blog.

 So I start the setup app, and everything is going great until the install almost finishes and goes into the configuration wizard, which then wants me to enter in my database information.  Now, I’m no SQL Server expert, but I (foolishly) think – how hard can this be?  I try the defaults – create the default database name on the locally running SQL Server.  Well, the installer freezes for about 30 seconds and then comes up with an error messagebox saying that it can’t talk to the database or I gave it invalid credentials.  Since SQL Server 2005 Express is supposed to used integrated Windows authentication by default and I am running the installer as admin (and told it to use integrated Windows authentication, per recommendations), I discount that possibility for the moment.

 I remember back to when I setup SQL Server 2005 half an hour ago, and it having said something about disabling all remote network access (a good thing from a security perspective!).  So, I figure, something must be stupid here and is trying to connect with one of the network transports instead of one of the local transports and that is why things are failing.  I (foolishly, as it turns out!) try to cancel out of the Community Server configuration wizard so that I can reconfigure SQL Server 2005 to enable network access.

 That was mistake no. 1. The Community Server installer comes back into focus with a big happy “setup was successful!” dialog and no option to go back and re-run the wizard.  Oops.  I had to uninstall the *whole thing* and reinstall it to get the post-installation configuration wizard back (which had failed, mind you, not ran successfully!) after reconfiguring SQL Server.  So, after waiting around for the Community Server installer to take its time, I get back to the SQL Server selection dialog.  Again, no dice – nothing I enter seems to appease it.

 Now, I’m starting to get pretty annoyed.  This was supposed to be a quick and easy thing to setup, not something that I wanted to spend my whole afternoon on.  Well, after doing a bit of research on how SQL Server works (not exactly what I was expecting to have to do, this was supposed to all work out of the box, remember?), I figure out that the default configuration is supposed to listen on port 1433 if you selected TCP/IP for a network transport (which I did, for the SQL Server 2005 Surface Area Configuration Wizard thingie).  Well, a “netstat -anp tcp” says that nobody is listening on that port.  Oops, something is clearly wrong here, even though I followed all of the rules and used the supported UI and everything to configure SQL Server.  Well, I start poking around a bit more with the management tools that SQL Server installed, and eventually I got to where you tell the TCP transport which IP addresses that it should listen on.  I figure that maybe I need to manually tell SQL Server to listen on the IP I want on port 1433 here, if it wasn’t already (even though the TCP transport was enabled according to everything I could see).

 Now, this is a prime example of how you should not design a UI.  The UI for selecting the IP addresses/interfaces to listen on is vaguely reminsicent of the Visual Studio property pages where you have a column of property types (descriptions) and a column of property values (that you enter in to configure it).  Each IP address has a bunch of options that you can pick in this form.

Unfortunately, because I had turned on IPv6 support for this box, it has about 26 IP addresses (due to IPv6 over IPv4 automatic tunneling interfaces) between all of the VMware virtual NICs and the two physical NICs in the box.  And all of the IP addresses were “expanded” by default, in this tiny listbox that only had room for one and a half a property set per IP address.  To make matters even worse, the IP that I wanted to enable the listern for was #3, but the sorting for the UI was wrong – it goes 1, 10, 11, … 2, 20, 21 … and so forth, so the third IP address was at the *end* of the list.  Great UI here, guys!

 Anyways, after agonizing over that particular piece of user interface meets train wreck, I (or so I think) tell SQL Server to listen on my internal LAN IP for port 1433, hit OK, and restart the service.

 Then, I go try hitting “Next” on the Community Server setup.  Again, it doesn’t work.  Back to netstat and SQL Server STILL isn’t listening on port 1433.  Aaargh!  Well, next I do a “netstat -anpo tcp” and match the listening process IDs and port numbers with the SQL Server process ID to see if SQL Server is actually listening on ANYTHING.  It turns out that it IS listening, but on some completely unexpected (to me, anyway) port – 1398.  Huh??  The TCP transport uses 1433 by default!  Furthermore, I had configured it through the UI to listen on 1433.  Well, not being an expert on SQL Server, I start hunting around for how to convince Community Server’s setup wizard to use port 1398 for a remote TCP connection (still having no idea why the local connection mechanism doesn’t work, as that too is enabled in the SQL Server configuration manager).

It turns out that I have to go and define a “connection alias” in the SQL Server Native Client Configuration section of the SQL Server manager UI.  After filling in everything here – connect to the IP that SQL Server was listening on with port 1398, and hitting OK, I went back to the Community Server setup wizard and hit Next, praying for it to work.

 Success! Only about 2.5 hours into the installation attempt, I’ve at least got it talking to the database.  The next steps are to give it my initial account and password for the Community Server administrator account when creating the database.  I enter in the information and continue through the next steps in the wizard, and finally get to the end.  After hitting the last “Next” button, naturally, I get an error message; Community Server failed to create the database properly.  I am then presented with a Notepad view of the setup log, where the problem is quickly evident – apparently, the Community Server setup app didn’t both to escape its strings before passing them to SQL queries, and blew up because the password I used had a ‘ (single quote) in it.  This is just giving me warm fuzzies about how safe Community Server is going to be against SQL injection attacks, if I ever got it working, let me tell you.

So, I back out of that part of the wizard and pick a new password that doesn’t have any characters that are unfriendly to SQL if not properly escaped.  Now I get ANOTHER error at the end of the wizard; the setup program failed to create the database because it already exists.  Apparently, the wizard doesn’t roll back all of its changes if it fails partway through, and some of the database goo from the unsuccessful previous configuration attempt is still there.

 So, then I’m back to uninstalling and reinstalling Community Server for about the 5th time today, and getting madder every minute.  After the reinstall finally finishes, and I reenter all of my information yet another time, the configuration wizard actually completes without any visible errors (yay!!!).  So, the last thing the wizard wants to do is launch the Community Server site for the local IIS install so that I can see all of the Community Server goodness that is now installed.

Guess that?  The site doesn’t load.  Instead, I’m presented with a 404 Not Found in my browser window, from the URL that the configuration wizard so nicely launched at completion.  Apparently, there were several problems here: default.aspx wasn’t properly registered as an index document, and Community Server had picked the wrong IIS site to configure itself on (without even asking me which one I had wanted).

At this point, I’ve had it – after having burned a couple of hours on this problem, I’m just not willing to give it any more of my time.  I uninstalled SQL Server and Community Server and went in search of other alternatives, which lead me to my current blog software, WordPress.

 WordPress is not exactly what you would call a native Windows solution – it relies on PHP, and the only backend database provider that it can talk to is MySQL.  None of these were really designed to work on Windows, but nonetheless, at this point I’m ready to try anything that doesn’t touch SQL Server or doesn’t have Community Server in it’s name.  All in all, it only took me about 15 minutes to download everything I needed (from various sites, too, not one centralized location) to get WordPress to work on IIS (Win32 PHP 5, Win32 MySQL, and of course WordPress itself), work through one or two minor setup hiccups (made a typo in the database user password in the MySQL console once, forgot to tell PHP where to find php.ini, forgot to enable the PHP MySQL extension dll), and get everything working.

 Wow.  Now, I’m not what you would call a Unix guy – I do as much as I can on Windows and avoid Unix whereever possible, and here I am, having figured out this “crude” set of tools that don’t even have any friendly, advanced setup wizards or anything (well, MySQL has a relatively nice GUI setup, actually), learned how to create the database that WordPress needed myself in MySQL, and debugged setting up a complicated ISAPI extension in IIS with partially outdated documentation in a mere fraction of the time as what the leading Windows solution (with it’s do-everything-for-you-the-right-way setup wizards and all) took to get into an almost-working state.  I hate to admit it, but sometimes software that came from Unix just does things better sometimes.

This entry was posted on Wednesday, July 5th, 2006 at 10:33 am and is filed under Blogging, Debugging. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.