[kforge-dev] [knowledgeforge-user] Issues with svn and knowledgeforge

[John Bywater]

Hi Rufus,

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"
http://code.google.com/p/modwsgi/wiki/ApplicationIssues

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.

Best wishes,

John.



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.
>
> Rufus
>
> 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).
>>>
>>> Rufus
>>>       
>> Rufus,
>>
>> I see you've got your wish :)  Do you know when you're likely to
>> be able to schedule this upgrade?
>>
>> many thanks,
>> mark
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/kforge-dev/attachments/20090310/d3885dc7/attachment-0001.html>