How to fix the ugly ass Ubuntu boot splash OR Damn, Ubuntu, you ugly

TL;WR: http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml

If you've had Ubuntu for a while and you've got an nVidia video card, chances are you've got the ugly ass default boot screen. Fortunately, you can fix this. You just need to follow the instructions above. I hope you're comfortable with the command line.

Changing the password complexity requirements on Windows Server

To change the password complexity requirements on Windows Server (2008 at least) (for whatever reason), do the following :

Start -> Run -> gpedit.msc -> Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

Then in the right-hand policy pane, set 'Password must meet complexity requirements' to 'Disabled' (right-click -> Properties)

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved

Journey to robust windows services: debugging your WiX custom actions

I've recently had some trouble getting WiX custom actions to work, and after searching around for a while, I found this article. It gives the reader two options for how to debug WiX custom actions, but I had to use both in combination to get it to work. I'll repeat the steps here, just in case the link goes stale:

1. Follow all the necessary steps to create a WiX setup project, along with a separate Custom Action project (available as a project type in the New Project dialog in Visual Studio 2010+ with WiX 3.7)
2. After you've created your custom action method and gotten the project building, add System.Diagnostics.Debugger.Launch(); at the beginning of your custom action method. This will kick the custom action into the debugger so that you can debug it (assuming you've got the wixpdb in the same directory from which you launched the installer).
3. Go to Control Panel -> System -> Advanced System Settings -> Advanced (tab) -> Environment Settings (button) -> System Variables (group) -> New .... (button) 
4. In the dialog that comes up, create a new variable called 'MMsiBreak' (without the quotes) and give it the value of your custom action method (e.g. MyCustomActionMethod)
5. Now run the debug version of your installer and it should get kicked right into your method and allow you to debug your custom action.

Journey to robust windows services: creating custom actions for your WiX installers

I've lately been trying to update my WiX installers to perform custom actions so that I can do some security configuration of my applications after they're installed. I got started with this article on CodeProject, but it was missing some information. Apparently, in addition to creating the separate project for the CustomAction DLL, you need to include as part of that assembly a CustomAction.config file with the following contents:

xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v4.0" />
    </startup>
</configuration>

But what really got the thing working was targeting the CustomAction DLL to .NET framework v3.5, rather than 4.0 because I was getting some bad image format exceptions when trying to run it. Thankfully I found the MSDN article on enabling MSI logging. These two articles on stackoverflow.com also really helped out.

Journey to robust web services: installing a WCF 4.0 application on IIS 6.0

Due to budget and other constraints, I'm unable to get my hands on the latest and greatest software for running a WCF application I've been working on, so I'm forced to use what my company's got: Windows Server 2003 and IIS 6.0. Suffice it to say that working with these old bits of software are less than ideal. However, I'm stuck with it. So, moving forward, here's some of the things I found while working on the application:

1. There's no easy way to set certain items in the registry for the Network Service user. (Sorry, for various reasons, I can't elaborate on that statement.)
2. Due to (1), I've decided to run my application as a custom normal (non-Administrator) user that I've created. However in order to use this user with IIS and its applications, certain steps must be taken.

Using a custom user to run an IIS 6.0 application

The following are pre-requisites in order to be able to use a custom user to run an IIS 6.0 application:

• The user must have already been created and should have absolutely the least number of privileges possible.
• Thanks to this question on Stack Overflow, the following must also have the following:
• The "Log on as a service" right (Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service)
• "Access this computer from the network" (similar location as in the step above)
• "Deny logon locally"
• "Log on as a batch job"
•  "Read & Execute", "List Folder Contents" and "Read" access to the file system that underpins the web site/application
• Thanks to this troubleshooting article on MSDN, I also found out that the user must be part of the "IIS_WPG" group.

I now have other problems to worry about with this application, but at least now I know that they're not related to how I'm running the application in IIS.

Journey to robust web services: apparently we shouldn't use 'using'

I recently stumbled across an article stating why we shouldn't use the 'using' keyword with WCF services, and I found it rather interesting. I'd have to re-read it, and re-evaluate it, before I use it but you can read the blog post on the original site.

Journey to robust webservices: kickstarting use of certificates phase II: using certificates for client authentication

There are a number of means of authenticating users, and one of the most secure is via a certificate. This article on CodeProject provides a start. Unfortunately, the article doesn't really mention a few things:

1. Depending on how you ran the tools, you may have inadvertently run the commands it gives you as an administrator. I ran them in a console that I already had open that was running as administrator, so they were installed as administrator, and I also happened to have been running in Visual Studio as an administrator at the time, so everything happily worked. Then when I rebooted my machine this morning and was running as a normal user, nothing worked, and I wasted over an hour trying to figure out why. That was why. Regardless of how you generated and installed the keys, you should go and explicitly grant permissions on the key to the users you want to have access to them. On the Microsoft website, there is a bundle of WCF samples (which you can find here). Included in the samples is a tool called FindPrivateKey. Download the samples, compile the program, and use it to find the key that you just generated. You'll need a command similar to the following : "C:\Samples\WCFWFCardSpace\WCF\Tools\FindPrivateKey\CS\bin\FindPrivateKey.exe My LocalMachine -t "28 ce e3 2c 7e 05 3a 97 a0 b4 92 fd d5 b0 f9 de 0e 4c 2e 4b"" where the value in quotes is the thumbprint of the non-signing (client) key you generated in the instructions from the article. Once it spits out the location of the file, you'll need to go and alter its permissions to allow whatever user your server / client application is running under access to the file.
2. Depending on the binding you're using with WCF on the server side, you may need to have a certificate with full chain trust on the IIS server (or other?) in order to use the binding (*cough* basicHttpBinding and any other transport-only security bindings *cough*). With that in mind, after you've generated the certificates in the article, while you're in the certificate manager MMC snap-in, you'll also need to copy (not move) the IIS developer certificate used in IIS to the "Trusted Root Certification Authorities" store.

Journey to robust web services: kick starting use of credentials and certificates for message security, phase I

As any sensible developer of a large scale system knows, security is paramount. Therefore, encryption of sensitive data is an absolute must, encryption of all data is recommended, depending on the field in which you're working. Encryption with WCF is baked in, and is relatively straight forward to setup, though there are a number of important details to which attention must be paid. The steps are somewhat different depending on whether you're using IIS or a self-hosted service (e.g. in a Windows Service).

If you're using a Windows Service, you'll need to perform the following steps to get started:

1. Generate a self-signed certificate (which can be done in the Windows Control Panel)
2. Configure the port to which you're binding the service with the certificate you've just generated, according to this MSDN article. 
3. [to be continued]

If you're using IIS, getting started in a development environment is somewhat simpler.

1. Generate a self signed certificate with IIS. In most cases, IIS will have a developer certificate already installed that you can use.
2. Retrieve the thumbprint of the certificate. You'll need this in order for your application to be able to find it at runtime. WARNING: Don't just copy the thumbprint out of the certificate properties window in IIS, because there are non-printing characters in the text control that will cause you problems when you try to paste the thumbprint into your Web.config file. Write them out by hand.
3. There are two methods you can take for making the certificate available to your WCF service:
1. Follow the guide here if you want to make the certificate available to your application by code.
2. Use the information on this page to create a element underneath a configuration/system.serviceModel/behaviors/behavior/serviceCredentials element.

Journey to robust web services: debugging services and logging messages

One of the quickest and best ways to debug issues with the services you're developing is to log and trace all activity with WCF along with the messages being sent back and forth. This page on MSDN will provide you with the instructions required to setup logging and tracking for WCF.

Journey to robust web services: my clients are unable to connect!

I've been testing out some web services I've been working on extensively on my own machine, but the time has finally come where I want to start making clients that aren't running on the same machine. In one case, I have a WCF service running on Windows 7, but the client I want to connect to that service is running on Windows 8 on a separate machine. When I tried to connect, I would get a variety of errors, the most common of which being that the socket on the server was forcibly closed. I Googled around a bit, and the most common cause of this problem that I found was that the server's quota's were being reached and therefore the client was being rejected, however this shouldn't have been the case for me since there was no way my quota's could have been reached. After further research, I found that since I don't want security (yet), I had to apply some settings in order for clients that weren't on my localhost to connect. In order to allow external clients to connect, I had to change the following :

1. In my , I had to change my base address to use the network name of my computer (rather than localhost) in the base address URL.
2. In the net.tcp and ws2007HttpBindings for my services, I had to go to the the child element of the elements, and explicitly set mode="None" on those elements, otherwise they may assume some form of security by default depending on the type of the binding.

Now, I did mention above that I don't want to add security (*YET*) being the important qualifier of that statement. Security is of course always paramount, and should always be baked into a product as early as possible. As soon as I get to it, I'll add a post about all the steps required to add security to your WCF clients and services, along with links to the relevant MSDN articles (and any other useful ones that I may find.

Mono.Options installation, and getting StyleCop to ignore a file

I've recently discovered the Mono.Options library (available via NuGet) that lets you easily parse arguments passed into a program. Unfortunately, the ease with which a package is typically installed via NuGet does not apply to Mono.Options because it's a single .cs file that gets included in your project, rather than a signed assembly. This becomes an annoyance in projects where StyleCop is used to enforce coding standards. Fortunately, there is a way to get StyleCop to ignore specific files (rather than forcing me to tweak my StyleCop settings for the project) which I found out about here. The TL;DR for that article: edit your project file, and underneath the element for the offending file, insert a <ExcludeFromStyleCop>true</ExcludeFromStyleCop> element.