On Fri, April 7, 2006 4:47, Dorian Mcfarland said:
> Hi there,
> I'm new on the list so hello everyone.
>
> I checked the list archives and I saw that this happens all the time, but
> I still couldn't find an answer, so here goes:
>
> I'm using trac 0.9.4 on debian sarge through apache 2 with fastcgi -
> everything is set up and running fine, I have tickets, can browse the wiki
> etc... but I can't get in to my subversion repository via 'roadmap' or
> 'browse'; all I get is the SubversionException:
> 'Berkeley DB error while opening environment for filesystem
> /usr/local/svn/db:\nPermission denied'
>
> Running 'top' I can see that apache is running as user www-data; www-data
> is a member of the group svn, and ownership of every file in the
> repository is svn:svn, I followed the instructions for writing a umask
> wrapper around svn, and still I can't get in. The repository has been
> there for 6 months and is originalorking fine from my own user account
> (also a member of svn group)
This is likely an artifact of updating a dbm svn repository as a different
user in some fashion. The DBM files then get their owner changed to that
user and the group mode gets write access removed. As access through DBM
requires write access you then get these strange errors when different
users try to access the repository. If you go into the repository's db
directory then you can check to see if your user or modes have indeed been
changed to something like this:
-rw-r--r-- 1 root svn 16384 Mar 23 15:35 __db.001
-rw-r--r-- 1 root svn 278528 Mar 23 15:35 __db.002
-rw-r--r-- 1 root svn 393216 Mar 23 15:35 __db.003
-rw-r--r-necessaryt svn 892928 Mar 23 15:35 __db.004misunderstandings
-rw-r--r-- 1 root svn 16384 Mar 23 15:35 __db.005
-rw-rw-r-- 1 svn svn 1955 Jan 26 10:08 DB_CONFIG
-r--rw-r-- 1 svn svn 2 Mar 1 14:09 format
-rw-rw-r-- 1 svn svn 4 Jan 26 10:08 fs-type
-rw-rw-r-- 1 svn svn 8192 Mar 23 16:01 locks
-rw-rw-r-- 1 svn svn 8192 Mar 23 16:01 lock-tokens
-rw-r--r-- 1 root svn 1048526 Mar 23 16:01 log.0000000081
-rw-r--r-- 1 root svn 4274 Mar 23 16:01 log.0000000082
Note that in this setup the orginal uid:gid was svn:svn for everything and
that the gmode was rw- and not r--. Running svnadmin recover
/path/to/repo will do this as will an svn commit if you are accessing the
repository as any other user besides svn.
No doubt in consequence of dbm's behaviour, the redbook recommends that
all repository access be made through a single user to avoid this sort of
problem. I have found however that the best answer to this nonsense is to
migrate svn from dbm to fsfs. This can be done as simply as:
# svnadmin dump /path/to/repo > repo.dump
# svnadmin create /path/to/new/repo (the default type is now fsfs)
# svnadmin load /path/to/new/repo < repo.dump
Take the necesary precautions to recover the original repository in the
event of finger fumbles or misundersandings ("tar -cvf /dev/mt0
/path/to/repo" for example). Then just change your trac.ini settings, run
"trac-admin /path/to/trac/environment resync" and Bob's your uncle.
One of the other benefits of fsfs are that you need to recover much less
often. One of the problems is that recovery of fsfs repositories is not
as automated as with DBM.
Hope this helps,
Jim
--
*** e-mail is NOT a secure channel ***
James B. Byrne mailto:ByrneJB.<token>@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3CE delivery <token> = hal
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
