The main aims of the project were to fix a number of bugs, upgrade the backup and improve the reposisivness of the client and admin commands

The bugs could roughly be broken down into

Client bugs 54778 52684 52624 52375 52178 52024 51299 56091

server side bugs 51931

auth bugs

Requests for enhancement 54779

Operational errors

Work on the project coincided with the upgrade to Sl6 and it soon became apparent that on both the client and server sides a number of the issues were solved by upgrades in coltex client software dependencies to versions available in SL6. As such it was decided to push the upgrade of coltex, including the server, to SL6 as quickly as possible rather than working through bugs individually. Consequently a test Sl6 based coltex client and server was set up and most client issues dissapeared in the sl6 test client machine, The sl6 test server seemed to work ok except for authentication. mod_authz would only authenticate directories where the parent directory was world readable.

Authentication problems Initially the authentication problems were thought to be a misconfiguration or a bug in mod_authz but after some investigation (and at the suggestion of Toby) we looked at how the mod_dav_svn module interacts with the subversion server. mod_dav_svn allows admins to modify how authentication works via the SVNPathAuthz directive. Access control to files and directories in the Apache/mod_dav_svn/subversion server stack can be complicated in that authenticationa and authorisation can be controlled via both apache or subversion, or by combinations of both. In terms of controlling authentication Apache and subversion authorisation directives can interact with (or indeed interfere) with each other down to a file level acuity. Apache directives are path based whilst subversion maintains it's own acl database.

Our issues were not with the Authentication part of the process but wth authorisation to access top level svn repository directories and specifically in how mod_dav_svn interpreted the apache and subversion authorisation directives and how a bug in the module had been fixed. For Coltex, we have two repository hierarchies: one holding admin/metadata on the various projects and another holding actual project content. Both of these hierarchies contain multiple layers of subversion repository and in both cases the top level svn repository needs to be at least readable to all authenticated users. In the case of the project hierarchy access rights may be layers deep as we allow nesting of projects. Mod_dav_svn can be configured via the SVNPathAuthz directive either to verify all paths accesses by svn command (on), to query svn for each path (short_circuit) or to rely on svn for authorisation (off) A bug ( was found in the code supporting this directive and the fix caused the issues described above. Consequently we have switched to relying on svn authorisation which has been patched in versions above 1.6.13


In parallel to the investigation of the authentication problem we looked at provide a backup using svnsync. Svnsync is a sunversion admin tool which will mirror a subversion repository by replaying the subverison commit logs from a source repository into a destination. The destination is usually a newly initialiased repository but it can be an earlier version of the repository being mirrored. Syncing can be done synchronously, via post-commit hooks or asynchornously by eriodically running the svnsyn command.

Since large chunks of the svnsync code and resources would mimic the subversion component in setting up and admining the mirror repository svnsyn was written as a perl subclass of the svn component. During developemnt and initial testing this involved having the "bodge" of having a slightly modified copy of the svn component in a more appopriate place in the perl filehierarchy with a one line modification. Normally the svnsync command is run using a post-commit hook, provision is provided in the config to specify post commit scripts (and directories of scripts) to be called prior to the sync script and also for scripts to be called after the syn is done. Obviously any post sync post-commit scripts should not modify the repository otherwise the repositories will not be mirrored properly.


This report has been caught up in development hell for some time because the project finished about the same time as the development process was revamped and it got stuck down behind the back of the sofa cusions

Conclusions: lessons learned

Iain Really need to keep on top of his paperworkl.

time spent:

28.5 days,

-- IainRae - 18 Jan 2016

Topic revision: r2 - 02 Feb 2016 - 10:15:01 - IainRae
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies