Some experiences of installing Kallithea on Windows
Konstantin Veretennicov
kveretennicov at gmail.com
Wed Mar 30 22:23:11 UTC 2016
On Mar 30, 2016 22:26, "Mads Kiilerich" <mads at kiilerich.com> wrote:
>
> On 03/29/2016 09:25 PM, Konstantin Veretennicov wrote:
>>
>> 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.
>
>
> So you were following
http://docs.kallithea-scm.org/en/latest/installation_iis.html ?
Yep, to the letter. (Which reminds me that there was also an error about
--root=/ not recognized as valid arg... is this part of documentation
fresh?)
>
>> 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.
>
>
> Did you use win32traceutil as mentioned in the documentation?
Sure, but it stayed dead silent. I even checked from interpreter whether it
worked at all - it did. I concluded that isapi-wsgi didn't get a chance to
write to it, because of a very very early crash. Which is consistent with
Failed Request Tracing not producing anything (I checked separately that
FRT works).
>
>> 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.
>
>
> Why was that weakness?
Compared to compiling my own? :)
I'm not fond of downloading semi-official binaries from the web.
>
>> 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.
>
>
> What part of the documentation left you having to do trial and error? How
could it have helped you?
I'm not sure Kallithea documentation has much to improve here. It's just
those nitty-gritty details of LDAP itself and AD's implementation of it,
like filter expressions, ports and protocols.
At some point I thought "I know, I will look up the correct settings in our
Jenkins installation!" - it also uses LDAP/AD. I was surprised to see only
a couple of settings in its configuration, none of them customized. It just
worked with AD out of the box.
>
>
>> 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".
>
>
> That doesn't sounds like a helpful advice. But it would be nice to get
the documentation improved to help with the problems you encountered and to
set the expectations right and mention the pros and cons.
Don't know how it sounds, but as soon as I get a time machine that's the
message I will deliver to my past self :) Because it works just fine with
LDAP and we could have started using Kallithea one day earlier.
Anyway, I phrased it differently in the small PR
https://bitbucket.org/conservancy/kallithea/pull-requests/213/docs-add-warning-about-iis-windows/
> /Mads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160331/e55a51d0/attachment.html>
More information about the kallithea-general
mailing list