Friday, May 18, 2012

Installing MonoDevelop 3 on Ubuntu Oneiric and Mint 12

I really like being able to develop in .NET on linux, and I think that the mono team has come a long way in its efforts to make mono-based applications production-viable.  Sadly, I'm guessing that the majority of mono developers use mac, opensuse, or windows because those are the only platforms that dependably have pre-built binaries and installers.  Since I use Mint (a variant of Ubuntu), I'd really like a simple method for installing a current version of MonoDevelop.

Recently, I needed to install Mint on my new laptop and so I payed close attention to how I installed MonoDevelop and turned it into a script -- which you can now use!  I've tested it on a fresh Mint 12, but it should also work on Ubuntu Oneiric.

The script:

  1. Installs the git client and the dependencies necessary to build MonoDevelop from source.
  2. Downloads the source code for MonoDevelop from github.
  3. Configures the build script to install the stable profile into /usr/local (/usr/local/monodevelop-3.0.1/ will be the full path).  However, you can change the defaults by editing the variables at the top of the script.  
  4. Builds and installs MonoDevelop
  5. Creates a script in $INSTALL_PREFIX/bin that simply calls the real monodevelop script.  This is because you can't just create a symbolic link.  This step has a bad smell to it - if you know a better way to do what I'm trying to do, please leave a comment.
  6. Adds two environment variables into your ~/.bashrc file
You should also know that it has a dependency on gnome-sharp2, so I don't know what to do if you're not using something based on gnome.  If you want to save some hard drive space after the install, you can delete the MonoDevelop source code directory that gets downloaded.

You can download it here: https://raw.github.com/jar349/tools/master/install-monodevelop.sh.

Don't forget to run it with sudo!


Thursday, April 12, 2012

Installing CouchDB 1.2 on CentOS 6

CouchDB has a really great idea behind it.  Whether or not CouchDB delivers on it, I've been wanting to discover for a while.  Only way to do that is kick the tires, so I started the process of figuring out how to install it.

First disappointment is discovering a general lack of documentation.  But my first appreciation is how simple it is once you figure out what needs to be done.

CouchDB runs on erlang, so you need to install erlang from the EPEL repository.  In order to use that repository on CentOS 6, run the following command:
sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
Now you can install erlang:
sudo yum install erlang
That will bring with it a number of dependencies, such as wxWidgets.  With erlang now available, it's time to download the CouchDB source code from here. As of this writing, the latest release is 1.2.0, although 1.3 is in alpha in master.  I'm electing to use the stable release.

Now that you have the source, unpack, configure, build, and install it.
tar zxvf apache-couchdb-1.2.0.tar.gz
./configure --with-erlang=/usr/lib64/erlang/usr/include
make
sudo make install
If you want to be able to reach the database from other computers on the network, you'll want to edit the configuration file:
sudo emacs /usr/local/etc/couchdb/local.ini
Under the [httpd] section, uncomment the bind_address setting and change the value to 0.0.0.0 if you want couchdb to listen on all available interfaces.

Also, since you've installed from source instead of from a package, let's configure CouchDB to run as a daemon that starts up when we boot.
sudo ln -s /usr/local/etc/rc.d/couchdb /etc/init.d/couchdb
sudo chkconfig --add couchdb
sudo chkconfig --level 345 couchdb on
Finally, let's create a couchdb service account that will run CouchDB, and then fix some file permissions to give the service account access to what it needs at runtime.
sudo adduser -r --home /usr/local/var/lib/couchdb -M --shell /bin/bash --comment "CouchDB Administrator" couchdb
sudo chown -R couchdb: /usr/local/var/lib/couchdb /usr/local/var/log/couchdb /usr/local/var/run/couchdb /usr/local/etc/couchdb
That's it!  You've installed CouchDB on CentOS 6!  Start the database with:
sudo service couchdb start
 You should now be able to get the welcome result by browsing to http://localhost:5984/ (unless, of course, you just installed it on a remote machine).

Time to Relax!


Tuesday, January 10, 2012

Invalid provider type specified when accessing X509Certificate2.PrivateKey

Today, I was attempting to digitally sign a byte array with my private key so that I could produce an event on the event bus and a consumer could ensure that the message came from me and was not modified while in transit.

public byte[] SignData(byte[] data)
{
  X509Store certStore = new X509Store(StoreName.My, StoreLocation.CurrentUser);
  certStore.Open(OpenFlags.ReadOnly);

  // the DN I get is CN=name,CN=Users,DC=example,DC=com
  // but the DN on the cert has spaces after each comma
  string spacedDN = UserPrincipal.Current.DistinguishedName.Replace(",", ", ");

  X509Certificate2 cert = certStore.Certificates
    .Find(
      X509FindType.FindBySubjectDistinguishedName,
      spacedDN,
      true)
    .OfType<X509Certificate2>()
    .FirstOrDefault();

  if (null == cert) { // handle no cert }

  RSACryptoServiceProvider rsaProvider = cert.PrivateKey as RSACryptoServiceProvider;
  return rsaProvider.SignData(data, new SHA1CryptoServiceProvider());
}

When I run this as myself, I get the following exception:  
System.Security.Cryptography.CryptographicException: Invalid provider type specified.
... the stack trace boils down to ...
System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
This wasn't a terribly enlightening exception message, so I asked google and found this link and this link.  It turns out that by using the newest Certificate Templates (version 3), I am using Microsoft's new Key Storage Provider (KSP), and not the Cryptographic Storage Provider (CSP) that we normally expect.  Windows Server 2008-based certificate templates use the KSP as part of what M$ calls Cryptography Next Generation (CNG).  While .NET 4 does provide managed implementations of the CNG stuff, they are not FIPS-compliant, which is a deal-breaker for me.

So what is a FIPS-constrained boy to do?  Well, I had to delete my auto-enrollment templates that were Windows Server 2008-based and replace them with Windows Server 2003-based templates.  When you duplicate a template using the Certificate Templates MMC snap-in, it will ask you to choose between 2008-based and 2003-based.  Select 2003-based and then revoke any certs you may have issued based on the 2008-based templates.  Let auto-enrollment take its course and then you'll find that you no longer get the invalid provider exception when you access your private key.