I have been struggling with cygwin on my Windows 7 64bit computer for a while. My first fix was to use the new 1.7.x version in which they claimed to have support for my os. Initially 1.7 seemed only to really support the 32bit version of Windows 7, but everyone seemed to have issues with incorporating it into the 64bit version.

Today I was doing a little research and someone suggested a user use mintty as a unix and Windows 7 solution. Since mintty was already installed on my computer with the cygwin setup.exe program, I figured I would give it a shot. I mean what could it hurt, and I have been really frustrated with the default Cygwin.bat shortcut on my desktop. To me it was too much like the dos prompt.

My first impression of using mintty was that the font looked a little different, but other than that, it was a huge improvement. Some of the advantages to mintty were:

• Mouse Wheel works with scroll bar
• Ability to Cut and Paste with mouse
• Windows Transparency
• Very extensive Mouse Support
• Native Windows Interface
• Based on the Putty codebase
• Options can be set for your terminal in a graphical interface

I really liked what I was seeing here so far. It is a much better interface than what I had been using in the past by a long shot. I love the way you can click on the screen and make it go fullscreen. You can even click on the screen, select options, and customize various options of your terminal.

My biggest frustration with cygwin on my computer currently has been when I tried to run fvwm. I have found that it would not run consistently when I initiated it from the cygwin.bat command prompt. I decided that I would go ahead and give this a shot inside of mintty, but figured I would just get the same old results. To my surprise, minitty executed fvwm a lot more consistently than before. There are still issues with it.

I am now done with the old way, and not looking back. Mintty is loads better than any shell interface I have used so far, and my cygwin environment is back and running again like the old days. I don’t even need to use fvwm now. The only reason that I was using fvwm was to support the mrxvt terminal, but mintty works 100% better on my machine so why even bother.

I have been working on a ruby on rails app where I needed to use the ruby-shout gem. Since I am trying to do my development on a Windows 7 computer, I found the easiest way to get everything working correctly was to install ruby and rubygems in cygwin 1.7. When I tried to install the ruby-shout gem I ran into a issue where it would not compile because libshout and shout.h were not found.

To get the gem installed I did the following:

$ cd /
$ curl -O http://www.artfiles.org/cygwin.org/pub/cygwinports/release-2/libshout/libshout-devel/libshout-devel-2.2.2-10.tar.bz2
$ bzip2 -cd libshout-devel-2.2.2-10.tar.bz2 | tar tvf -

This will extract the necessary files for you, and that is it. Now you can do a “gem install ruby-shout” and it will build and install correctly.

I love using Cygwin on my Windows machine. I have it setup to run the FVWM X-Windows interface. My terminal of choice for this system is mrxvt . Mrxvt does not come as a cygwin install but you can build it for the cygwin.

I found the installation instructions for doing this here .

Basically you need to make sure that you have the following packages installed on your system (There could be more, but I don’t know what they are since I install everything cygwin has to offer):

1) Cygwin base install
2) gcc
3) make
4) autoconf
5) automake
6) libiconv
7) the entire X11 category of packages
8) all of the cygwin rxvt packages
9) font-misc-misc

Next you will need to compile the code with the following commands:

$ ./configure --enable-everything --disable-debug
$ make
$ make install

Now you are ready to use it. I startup fvwm using the xinit command. You must make usre that you include the -silent-dup-error flag or mrxvt will have weird behavior. Here is how my xinit initialization script looks.

xinit -- -emulate3buttons -clipboard -silent-dup-error

Since I did not want to do that command every time I started fvwm I just created a alias to that command in the .bashrc file.

I was recently asked to get a Shibboleth SP setup to work with a Local version of IIS like one that is included in Windows XP Professional. The users were doing Microsoft .Net programming and wanted to do some Shibboleth SP Testing.

I followed the installation instruction for Installing Shibboleth SP on IIS6 . The installation went as described here with a few modifications.

When setting up your shibboleth2.xml file, leave the hostname to sp.example.org. It appears that the Shibboleth NSAPI filter does not recognize the local computer name, but says that all requests are being handled by sp.example.org. To trick this out go to the host file on your computer, usually located at c:\windows\system32\etc\hosts and add the following line.

127.0.0.1        sp.example.org

This will make all url calls made on your local computer to sp.example.org work.

Recently I was working on setting up a Shibboleth 2 SP that had multiple virtual hosts configured on it. Since nothing stays the same way for long, it ended up that we needed to point the Shibboleth SP at two different IdP's. I have easily done this in the past by setting up a individual SessionInitiator type for each IdP and then telling the SP where to go to by doing Lazy Initialization.

<SessionInitiator type="Chaining" Location="/Login-one" isDefault="true" id="Intranet"
        entityID="https://sso.one.com/idp">
    <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
    <SessionInitiator type="Shib1" defaultACSIndex="5"/>
</SessionInitiator>

<SessionInitiator type="Chaining" Location="/Login-two" isDefault="false" id="Intranet-beta"
        entityID="https://sso.two.com/idp">
    <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
    <SessionInitiator type="Shib1" defaultACSIndex="5"/>
</SessionInitiator>

Now that there are two Session Initiators you can authenticate to the first IdP by just going to the web page, since it is setup as default. You can also call /Shibboleth.sso/Login-one to call the first IdP. If you wanted to call the second idp you can all the /Shibboleth.sso/Login-two address.

This works great, if you have one site that needs to authenticate via multiple identity providers. But if you are running multiple sites on your Shibboleth SP and you want to choose which Identity Provider gets called, then you can do this by using the entityID attribute on the Host element in the shibboleth2.xml file as shown bellow.

<Host name="site.one.com" applicationId="app1" authType="shibboleth" requireSession="true"/>
<Host name="site.two.com" applicationId="app2" authType="shibboleth" requireSession="true" entityID="https://idp.two.com/idp"/>

Now we have setup the Host section to secure the domain site.one.com with the default session initiator of https://sso.one.com/idp. Since we wanted site.two.com to be directed to the second session initiator https://idp.two.com/idp we added the entityID attribute the the appropriate Host domain name. This will now make all authentications going to site.two.com be sent to the second IdP by default.