On Thu, Jul 21, 2011 at 4:54 AM, Andy Canfield <andy.canfield_at_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.
Received on 2011-07-21 17:38:06 CEST