Some experiences of installing Kallithea on Windows

[Konstantin Veretennicov]

Hi,

I was setting up Kallithea for our small team, to replace hgweb.cgi installation
that didn't cut it anymore, especially when it came to code review.
Email + hgweb are very flexible and you can go a surprisingly long way with just
that. But they're not enough for tracking which changes are still to be reviewed
or integrated.

Since our infrastructure is all Windows, Kallithea had to be installed on
Windows Server 2012 R2 (*duck*).

I got an experimental installation inside virtualenv up and running fairly
quickly. We did evaluation with the team and I proceeded to "production"
install. The main thing to solve was making it work with our existing Active
Directory accounts.

So I made a fatal decision: decided to put Kallithea behind some proxy with
Windows Authentication support and configure container auth. That way I hoped to
get a single'ish sign-on. My initial attempt was with IIS and ISAPI WSGI. I soon
discovered that it meant pywin32 dependency, which is no friend of virtualenv -
so there goes virtualenv. Anyway, when everything that had to be installed and
configured was finally installed and configured (including ISAPI support in IIS,
application pool settings, etc.), all this managed to produce was mysterious
death of IIS application pool process whenever a request was sent to it. What
made me abandon this track was complete lack of diagnostics: apart from Windows
Event Log talking of sudden crash of w3wp.exe - nothing of substance. The crash
must be happening quite early in IIS request pipeline, because IIS Failed
Request Tracing did not produce anything at all for these failures. I didn't
want to bother with crash dump collection and full debugging, so moved on.

Second idea was to use Apache for Windows with mod_wsgi and mod_auth_sspi as a
substitute for IIS. That seemed promising, especially since I've heard people
report success running Kallithea in mod_wsgi. Here I quickly got stuck trying to
assemble a matching combination of binaries of Apache 2.4 for Windows
+ Python 2.7 + mod_wsgi, all compiled against same CRT version and amd64 arch.
Since I am not so experienced with Apache, entire idea quickly lost its luster.

I briefly considered IIS ARR, which is a sort of reverse proxy, among other
things. However, the more I read about it, the more it felt tricky and not
well-documented for my use case.

Growing a bit desperate, I stumbled upon a reference to IISProxy, which is even
mentioned in TurboGears documentation as a way to front TG apps with IIS. I had
to add ASP.NET to the Server for it to work, but hey. It turned out to be a very
simple device and it actually worked! After figuring out in which environ entry
Kallithea receives the user name (it was HTTP_REMOTE_USER, not the normal
REMOTE_USER or HTTP_X_FORWARDED_USER), the container auth module successfully
created and authenticated user passed by IISProxy. All this with no plaintext
credentials in sight, yay.

So, anyway... finally I got to the point where my wrong initial assumption
became obvious :) - the assumption that Mercurial will authenticate against this
setup. But Mercurial client doesn't do Windows Authentication, only Basic.
Which (as I immediately remembered) I already discovered 5 years ago while
setting up our original hgweb...

I still fiddled a bit with IIS Basic Authentication, which validates
plaintext credentials against Active Directory, but it didn't work out
right away. For some reason Mercurial client got served login page instead of
repo data. There was probably some mistake here on my part that could be
debugged with a bit of effort, but at this point I was quickly losing steam.
Also it looked like a dead-end anyway, because even if it worked I was only
getting plaintext auth. So why not remove proxy from the picture and
authenticate with AD over LDAP.

Here the first hurdle was to get python-ldap binaries for Python 2.7 x64, which,
in a moment of weakness, I just grabbed from Gohlke. Then I had to figure out
correct LDAP settings. I managed that with the help of documentation, some trial
and error and my lucky rabbit foot. I think the key setting for me was "LDAP
Filter". Luckily, the Active Directory notes in Kallithea LDAP documentation
matched our own "Small Business Server" LDAP layout.

The last steps were piece(s) of cake, punching a hole in Windows firewall and
making Kallithea an NT Service with the help of wsgisvc. Here I wasn't sure
which folders need which permissions, so I left it running under (overpowered)
"Local System" account, which is wsgisvc's default.


I post this here mainly as a reminder to self to make a documentation PR with a
warning "Don't waste your time putting Kallithea behind Windows Authentication".

--
Cheers,
Konstantin