Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

ive been sitting on this for about 7 hours, and ive aged close to 7 years... ahhh, server admin does that to me.

i have svn wired through apache2 with webdav in the usual manner (basically like http://www.howtoforge.com/setting-up-subversion-with-webdav-post-commit-hook-and-multiple-sites-on-jaunty-jackalope-ubuntu-9.04). ive had endless problems with this (i didnt on my previous ubuntu server install, although this is ubuntu 10.10): this happened, and was fixed like in the post: http://stackoverflow.com/questions/2547400/how-do-you-fix-an-svn-409-conflict-error

this looks like my issue, although its not my solution: http://serverfault.com/questions/135494/apache-svn-on-ubuntu-post-commit-hook-fails-silently-pre-commit-hook-permis

my commit to svn works (finally). although the post-commit hook which is supposed to svn update the working copy of the repo on the server, doesn't work.

the post-commit hook itself executes, and has sudo permissions (as in the setup url above. testing with whoami >> somelogfile.log or sudo whoami >> somelogfile.log shows www-data and root, respectively), although it wont perform the svn update (sudo svn update /var/www/gameServer >> /var/svn/gameServer.log). similar to the serverfault url above, when i perform the exact command it does update the working copy to the latest revision, just not through the post-commit hook.

an age old question that is 90% of the time a permissions issue. but in pure frustration i chmod 777 lots of stuff not to mention the fact that www-data is in /etc/sudoer so it shouldnt even need that.

im collapsing in front of the screen partly out of frustration and partly out of sleepiness. any direction would be appreciated.

share|improve this question
    
One thing to remember after you get this fixed up is you really need to go back and remove the 777 permissions you granted while hacking on this. Don't forget to do a system wide find on 777 files and reduce them back to sane values. –  Caleb Oct 19 '10 at 10:54

2 Answers 2

From your hook script, call another script to do the svn updating. Limit www-data's sudo abilitys just JUST running that script. Don't accept any args.

From the script that will do the updating, make sure you su so the user that owns the local working copy you are updatin, like this:

in sudoers:

www-data ALL=(ALL) NOPASSWD:/usr/local/bin/update_my_thing

Hook script that get's called by svn and is running as www-data:

#/bin/sh
sudo /usr/local/bin/update_my_thing

Then in /usr/local/bin/update_my_thing

#/bin/sh
USER=usernam_that_owns_localsvncopy
su $USER -c 'svn up /path/to/localsvncopy'
share|improve this answer

do a sudo "cd /local/checkout/copy; svn update" or as a last resort, just add the job to cron and let it run every 5 minutes, in most cases such latency is OK and won't overwork the server

share|improve this answer
    
cron'ing stuff like this is an ugly hack. It might work for small repos and low traffic, but it will die and break and hog resources in larger environments. The post-commit hook is definitely the right way to do this and the permissions should be fixed so this work. The guy is almost there. –  Caleb Oct 19 '10 at 10:53
    
"as a last resort" –  Hubert Kario Oct 19 '10 at 16:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.