On Thu, Jul 21, 2011 at 4:54 AM, Andy Canfield <andy.canfi...@pimco.mobi>wrote:
> ** > More user/command interaction - > > The commands to create the Subversion Repository Parent directory were > * sudo bash > mkdir /data/svn > chmod a+w /data/svn* > This created this directory: > * drwxrwxrwx 4 root 4096 2011-07-21 17:36 /data/svn/* > > I ran this command as user root: > * svnadmin create /data/svn/sample* > and what I get is > * drwxr-xr-x 6 root 4096 2011-07-21 11:08 /data/svn/sample/* > > I ran this command as user andy: > * svnadmin create /data/svn/example* > and what I got is > * drwxr-xr-x 6 andy 4096 2011-07-21 17:36 /data/svn/example/* > > It concerns me that apache is running as user 'www-data' and niether of > these repositories are owned by, or even writable by, www-data. So I did > these commands: > * sudo bash > su www-data > svnadmin create geronimo* > The output of the last command was as follows: > * svnadmin: Repository creation failed > svnadmin: Could not create top-level directory > svnadmin: Can't create directory 'geronimo': Permission denied* > That surprises me; the /data/svn directory is writable by everyone. Ah > well. > > The browser, when pointing to http://localhost/svn/RepoName, gives this > answer > * RepoName - Revision 0: / > Powered by Subversion version 1.6.12 (r955767)*. > This is true whether RepoName is 'sample' or 'example'. Of course, the only > thing mod_dav_svn needs to do in this case is to read the repository, and > all files and directories are readable by everyone, regardless of whether > they are owned by root or andy. > > So the browser access mechanism has no commands to control a repository, > only to describe it? Logically this might make sense; however I would expect > that http://localhost/svn would be capable of listing the repositories and > creating new repositories.. But when I point the browser to > http://localhost/svn I get this response: > * Forbidden > You don't have permission to access /svn/ on this server. > Apache/2.2.17 (Ubuntu) Server at localhost Port 80* > When I look at /var/log/apache2/error.log I see these lines: > * [Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1] > Could not fetch resource information. [403, #0] > [Thu Jul 21 17:54:04 2011] [error] [client 127.0.0.1] > (2)No such file or directory: The URI does not contain the name of > a repository. > [403, #190001]* > Ahah! So http://localhost/svn is NOT a valid Subversion URL. I was > mistaken when I thought someone said that the Apache browser interface could > give me a list of the repositories. > > PROBLEMS WITH THE 'SVN' COMMAND - > As Linux user 'andy'. Here goes: > * rm -rf .subversion > ** **svn info http://localhost/svn/sample --username='andy' > --password=not-shown'* > * Password for 'default' GNOME keyring: > svn: OPTIONS of 'http://localhost/svn/sample': authorization failed: > Could not authenticate to server: rejected Basic challenge ( > http://localhost) > *The fact is that, as far as I know, I DON"T HAVE ANY %$#@! GNOME KEYRING! > So when it asked for the Password for 'default' GNOME keyring I just pressed > Enter. Then authenticiation failed. > > OK, so I have completely removed the gnome-keyring package. I also had to > wipe out the ~/.gnome2/keywrings directory. Now to try again. > > Wait. Wait some more. Go down to 7/11; buy a hot dog and some potato chips. > Come back home. It's been 20-30 minutes. Command still hasn't completed. > Nothing in /var/log/apache2/error.log. Just a dead svn program. Had to kill > -9. > > When it comes to plants, some people have a green thumb; I have a brown > thumb. Looks like when it comes to Subversion I have a black thumb. > > I feel for you, Andy. I had all these same problems you're having. The whole gnome-keyring thing is a bad decision IMO, or at least, to use only gnome-keyring or kwallet. Why they didn't leave the default password storage options from 1.4x is a mystery. You are definitely not the first person to have confusion and issues over this. >From what I read they changed the behavior between Subversion server 1.4 to 1.5/1.6 to use this new/different authentication scheme. I never fixed that on my server, either, on my server. I'm running Ubuntu Server 10.04 LTS and there is no desktop so there is no gnome keyring. I just keep saying 'no' when it asks to store plaintext passwords, and have to enter my password every command I do. This is okay for me because 95% of the commands I run are not on the server but from a remote client, and my IDE, both of which store my password for me. http://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/ If *you are not* concerned about the security issues surrounding storing plaintext passwords, then you can enable that option in the [global] section of your /etc/subversion/servers file: store-plaintext-passwords = yes If *you are* concerned about security issues like this, you can try gnome-keyring or kwallet. See the [auth] section of /etc/subversion/config There are tons of posts online about gnome keyring subversion -- most of which were way over my head unfortunately. http://www.google.com/search?q=gnome+keyring+subversion http://www.unix.com/shell-programming-scripting/157714-subversion-gnome-keyring.html This post https://bbs.archlinux.org/viewtopic.php?id=93186 says to export `gnome-keyring-daemon` but that doesn't help me at all on Ubuntu Server and the post is for Archlinux so I wasn't sure where that would go. I'm as curious as you are to solve this hurdle.