[kforge-dev] [knowledgeforge-user] Issues with svn and knowledgeforge
john.bywater at appropriatesoftware.net
Tue Mar 10 20:24:52 UTC 2009
Having looked at this all day, one thing to try is disabling PHP. :-)
# rm /etc/apache2/mods-enabled/php5.load
# /etc/init.d/apache2 restart
Then, try to commit an added file to the repository? Does it work?
If on a production box, do remember to enable PHP again.
# cd /etc/apache2/mods-enabled/
# ln -s ../mods-available/php5.load
It might be due to problem in Debian with the md5 library.
"Python MD5 Hash Module Conflict"
If the digest routine we use fails in "strange ways", the KForge access
controller might authenticate some times and screw up other times,
effectively change the assumed user, and inspire the "multi-user commits
not supported" error. I wasn't able to generate that error, but
nevertheless I couldn't commit successfully with PHP enabled for just
this reason. However, my machine was repeatedly broken: the md5 library
consistently failed to return the correct value when called from KForge
loaded in Apache with mod_php enabled.
If this is the trouble, we could either switch from MD5 to SHA1 in
dm/dom/person.py of domainmodel-0.6 (and cause a password migration
challenge for existing services), or advise reverse proxying PHP
applications (which seems rather dull), or think of something else.
Please let me know whether or not this works? Bet it doesn't. ;-) But if
not, I'll have to work a bit harder to replicate the bug, because I can
consistently commit a new file to a KForge 0.16 SVN service running on
Debian Etch with SVN 1.5.1 as Debian modules 'subversion' and
'libapache2-svn' from etch-backports.
Rufus Pollock wrote:
> Dear Mark (and other users),
> Thanks for the ping and sorry to not get back sooner.
> We tend to not rush into the total system upgrades (KForge uses a lot
> of packages many of which (e.g. trac) require per-service hand-run
> upgrades). Knowing that this was urgent however, we suddenly thought
> about using etch-backports to upgrade svn (we should really have
> thought of this before).
> Unfortunately having now performed the upgrade to svn 1.5.1 it seems
> the problem has *not* gone away :( This suggests it may be something a
> bit more subtle (and related to working of KForge auth/authz system).
> We're going to take a look at this asap and hope to have a fix very
> soon (it's not trivial to debug this problem because we need to have a
> test instance of KForge running using the relevant apache/svn/etc
> packages on which we can reliably getting a failing 'test'). Apologies
> for any inconvenience and we hope to have this sorted soon.
> 2009/2/15 Mark Longair <mhl at pobox.com>:
>> Rufus Pollock <rufus.pollock at okfn.org> wrote:
>>> Thanks for this Anthony and this continues to a be a really
>>> frustrating bug to track down. I still can't find any info on the web
>>> that would actually help me fix this. One option is to upgrade the
>>> server to use svn 1.5 and see whether that fixes things (we were
>>> rather putting this off until debian lenny shipped).
>> I see you've got your wish :) Do you know when you're likely to
>> be able to schedule this upgrade?
>> many thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kforge-dev