Thread: [Codestriker-user] rdiff failed -- permission problem
Brought to you by:
sits
From: David C. <dcc...@gm...> - 2008-01-23 01:58:35
|
On behalf of what user does the rdiff command run when using start and end tags? Currently I have two different deployments. One of them allows me to create a new topic using start and end tags. The other does not, but I can't see any difference. For the deployment that doesn't work, I *can* run rdiff from the command line and it works fine. When I use codestriker, I get the following: Problem generating topic text: cvs rdiff: failed to create lock directory for `/export/cvsroot/elvis/extreme/evpages' (/var/lock/cvs/elvis/extreme/evpages/#cvs.lock): Permission denied cvs rdiff: failed to obtain dir lock in repository `/export/cvsroot/elvis/extreme/evpages' cvs [rdiff aborted]: read lock failed - giving up (Note that we have configured CVS to place locks outside the repository.) Since I can run rdiff as user X from the command line, I know that I have permissions to do so. My theory is that when I create the topic and Codestriker runs rdiff, it uses a different user and hence the problem. I tried adding 'apache' to our /etc/group, which is how we control who can write a lock to /var/lock/cvs. This did not help. Any ideas about the user? Any other potential reasons this should fail when it works on the command line? What else can I compare between the two deployments besides the config files? Thanks, David |
From: <Ahu...@em...> - 2008-01-23 16:18:44
|
Have you tried the username you designated for Codestriker in your apache configuration file? Maybe you can put that username in your /etc/group file.=20 Thanks, Neeta =20 ________________________________ From: cod...@li... [mailto:cod...@li...] On Behalf Of David Carson Sent: Tuesday, January 22, 2008 8:59 PM To: Cod...@li... Subject: [Codestriker-user] rdiff failed -- permission problem =20 On behalf of what user does the rdiff command run when using start and end tags? Currently I have two different deployments. One of them allows me to create a new topic using start and end tags. The other does not, but I can't see any difference.=20 For the deployment that doesn't work, I can run rdiff from the command line and it works fine. When I use codestriker, I get the following: Problem generating topic text: cvs rdiff: failed to create lock directory for `/export/cvsroot/elvis/extreme/evpages' (/var/lock/cvs/elvis/extreme/evpages/#cvs.lock): Permission denied cvs rdiff: failed to obtain dir lock in repository `/export/cvsroot/elvis/extreme/evpages' cvs [rdiff aborted]: read lock failed - giving up (Note that we have configured CVS to place locks outside the repository.) Since I can run rdiff as user X from the command line, I know that I have permissions to do so. My theory is that when I create the topic and Codestriker runs rdiff, it uses a different user and hence the problem. I tried adding 'apache' to our /etc/group, which is how we control who can write a lock to /var/lock/cvs. This did not help.=20 Any ideas about the user? Any other potential reasons this should fail when it works on the command line? What else can I compare between the two deployments besides the config files? Thanks, David |
From: David C. <dcc...@gm...> - 2008-01-23 19:32:27
|
On Jan 22, 2008 9:42 PM, David Sitsky <dav...@gm...> wrote: > Hi David, > > > Since I can run rdiff as user X from the command line, I know that I > have > > permissions to do so. My theory is that when I create the topic and > > Codestriker runs rdiff, it uses a different user and hence the problem. > I > > tried adding 'apache' to our /etc/group, which is how we control who can > > write a lock to /var/lock/cvs. This did not help. > > That is correct - this command will be run as the same user running > apache. It would be worth running ps to confirm on your system that > it is indeed the username you think it is. > Well, apache was the correct username, but I could not seem to get it to recognize that apache was now a member of the group in question. The problem turned out to be that I needed to restart httpd after having made the changes to /etc/group. It was operating as if the group change had not been made. Thanks, David |