Bug in Subversion regarding file attributes
I created a repository and created a subdirectory in it named 'scripts'. In this are a half-dozen Linux shell scripts. Unfortunately, I set the execute flag on only five of them; the sixth was untested as of my first commit so I had never noticed that the execute attribute was unset. [1] I set the execute attribute and did a commit, but the file was not updated in the repository. Apparently the change in atributes was not recognized as a file change by Subversion. [2] I touched the file - I touched ALL the files in scripts, and none of them was updated on the commit. Apparently the file timestamp change was not taken as a file change by Subversion. OK, Subversion is not storing timestamps. [3] I edited the file, and this was taken as an update by Subversion. I just added a blank line to the end of it. But note that the file attributes now include the execute flag. I did another checkout, and unfortunately the execute flag is STILL not set. In my humble opinion [1] and [3] should have resulted in the file attributes stored in the repository being changed. So I did an svn delete for that file, then a commit. I restored the file from a backup, set the attributes, did an svn add for that file, then a commit. Went to another directory and did an svn checkout. OK; now the attributes are correct.
Re: Bug in Subversion regarding file attributes
On 08/21/2011 06:48 PM, Andy Levy wrote:
On Sun, Aug 21, 2011 at 07:21, Andy Canfieldandy.canfi...@pimco.mobi wrote:
I created a repository and created a subdirectory in it named 'scripts'. In
this are a half-dozen Linux shell scripts. Unfortunately, I set the execute
flag on only five of them; the sixth was untested as of my first commit so I
had never noticed that the execute attribute was unset.
[1] I set the execute attribute and did a commit, but the file was not
updated in the repository. Apparently the change in atributes was not
recognized as a file change by Subversion.
If the file's timestamp didn't change, Subversion won't pick up the change.
So does this mean that if the file's timestamp does not change, but the
files's contents change, Subversion will not pick up the changed
contents; svn only looks at the file's contents if the timestamp
changes? No checksum or filesize check, only the timestamp is used to
detect changes?
[2] I touched the file - I touched ALL the files in scripts, and none of
them was updated on the commit. Apparently the file timestamp change was not
taken as a file change by Subversion. OK, Subversion is not storing
timestamps.
If a change in the timestamp is detected, a checksum is done against
each file's pristine copy (and properties). If the checksums
properties match, Subversion doesn't flag the file as changed.
And according to [3], even if Subversion picks up the file as changed,
it does not pick up the attributes of the file as changed.
[3] I edited the file, and this was taken as an update by Subversion. I just
added a blank line to the end of it. But note that the file attributes now
include the execute flag. I did another checkout, and unfortunately the
execute flag is STILL not set.
In my humble opinion [1] and [3] should have resulted in the file attributes
stored in the repository being changed.
I disagree on #1, but for #3 I think it's only picked up when you Add the file.
Yeah, that's what it looks like. The file's attribues are set when it is
first added, and never changed thereafter.
So I did an svn delete for that file, then a commit. I restored the file
from a backup, set the attributes, did an svn add for that file, then a
commit. Went to another directory and did an svn checkout. OK; now the
attributes are correct.
You could have also set the svn:executable property on the file. If
you look at your newly-added copy of the file, you'll see that
property set now.
I am having a similar problem now with directories that need to be
globally readable. This happens because the repository contains a web
site, and the user ('andy') who checks out the repository is not the
user (Apache: www-data) who runs the PHP code. I have created scripts to
handle this but the user has to remember to run the script every time he
does a checkout. AFAIK there is no svn:writable property.
I am beginning to see that Subversion manages the CONTENTS of the files,
but does not do well at managing the ATTRIBUTES of the files.
Re: Bug in Subversion regarding file attributes
On 08/21/2011 10:52 PM, Mark Phippard wrote: On Sun, Aug 21, 2011 at 11:03 AM, David Weintraub qazw...@gmail.com mailto:qazw...@gmail.com wrote: What Subversion does is look at the timestamp of the file and the contents of the .svn directory that contains the file information. If the timestamp has been touched, it is compared against the base to see if there was an actual change. If you modify a file's property, it changes an internal file in the .svn directory and Subversion picks up that timestamp change. Just a point of clarification. Subversion looks at two things to determine if a file has changed. 1. The timestamp 2. The size If the file size has changed, then SVN considers the file modified. If the file timestamp has changed, then SVN does a byte for byte comparison with the pristine version of the file to determine if it has changed. WOW! So the .svn hidden directory contains a spare copy of every file in that directory??? Why not just store a computed checksum? This means that putting a directory tree under version control doubles the size of your working copy! A good way to make SVN really slow is to run touch on your entire working copy. That forces SVN to have to do a compare on every single file to see if it has been modifed. svn cleanup will repair the internal timestamps. -- Thanks Mark Phippard http://markphip.blogspot.com/ Conclusions: [1] Subversion will only suspect that a file has changed if either the timestamp or the file size has changed. [2] If Subversion suspects that a file has changed it will compare the file contents with a copy of the file stored somewhere in the .svn directory. [3] If a file has changed it will be uploaded in the commit. [4] File system attributes are only uploaded for a svn new; at all other times file system attributes remain as they were when the file was first added to the repository. So make darned sure you get the file system attributes correct when you first add the file. [5] To correct invalid file system attributes one must copy the file elsewhere, svn delete, commit, recover from the copy, svn add, and svn commit again. This works. It is not obvious that this will work, because although the file disappears from your working copy it is still in the repository. So svn add uploads the file attributes and svn commit *could* upload the file attributes but it doesn't. [6] The only file system attribute Subversion supports is the executable bit. Otherwise all system attributes are kept as of when the file was originall NEW-ed. Does this mean that if a file is NEW-ed under Windows then when it is checked out under Linux it will be writable by everyone, which is the default in Windows?
Subversion on Drupal
My goal in learning Subversion was to put our web site under version control. Now I have my doubts as to whether Subversion can handle it. The web site uses Drupal. And Drupal has the characteristic that much of the site is contained in a MySQL database. For example, if I install a module and set it up, the module is a disk file, but the configuration of that module is in the database. If I make a change, part of the change may be in a PHP code file on disk, part may be in the database. The database contains both user data and configuration data, intermingled. I could get Subversion to work. I would have a pre-commit script to back up the database to a disk file in the working copy. I would have a post-checkout script to reload the database from the disk file. Along with svn commit and svn checkout, this would give us the ability to roll back to any earlier version. What I can not imagine is how to get more than one person to be able to work on the site. Yes, Subversion would be able to merge changes to the disk files. But I don't see how Subversion can handle merging changes to the database. The MySQL database is text; perhaps someone here as experience with that. Can MySQL backup files be merged?
Re: Subversion on Drupal
On 08/12/2011 10:48 AM, Ryan Schmidt wrote: On Aug 11, 2011, at 21:56, Andy Canfield wrote: My goal in learning Subversion was to put our web site under version control. Now I have my doubts as to whether Subversion can handle it. The web site uses Drupal. And Drupal has the characteristic that much of the site is contained in a MySQL database. For example, if I install a module and set it up, the module is a disk file, but the configuration of that module is in the database. If I make a change, part of the change may be in a PHP code file on disk, part may be in the database. The database contains both user data and configuration data, intermingled. I could get Subversion to work. I would have a pre-commit script to back up the database to a disk file in the working copy. Not possible, because the working copy is on the client computer, whereas the pre-commit hook (and all hooks) run on the server computer. Unless you're saying you're working with a shared server-side working copy, in which case that's another thing I'd recommend not doing. My poor expression. It's not on a hook. I mean that when Charlie wants to do a checkout, Charlie must do this: [1] svn checkout ... [2] cd repository [3] scripts/post-checkout.sh My workstation shell script, which is stored in the same repository, takes care of reloading the database. I think that the script will work for both Linux and OS X; forget Windows. I would have a post-checkout script to reload the database from the disk file. There is no post-checkout hook, so this would have to be a script you run manually. Similarly, when Charlie wants to commit, Charlie must do this: [1] in GUI, do a Drupal manual backup (maybe I can trigger this in a script) [1] cd repository [2] scripts/pre-commit.sh [3] svn commit ... The pre-commit and post-checkout scripts try to take care of putting the database into the revision. They also take care of the problem that some files in some directories are created by, and therefore owned by, the Apache user and must be writable by the Apache user in any working copy. Subversion stores permissions but does not store ownership; a file owned by user www-data under Linux must be writable by user _www on OS X. And, of course, the scripts would have to fix any other problems I run into. Also I might need an UPDATE script.
Re: Subversion: list of respositories
On 07/18/2011 09:48 AM, Geoff Hoffman wrote:
On Sat, Jul 16, 2011 at 11:06 PM, Andy Canfield
andy.canfi...@pimco.mobi mailto:andy.canfi...@pimco.mobi wrote:
How do you get a list of repositories from svnserver? The only way
I can figure out is:
*ssh usern...@example.com mailto:usern...@example.com
sudo bash
ls -ld /var/svn/**
And, of course, this makes an assumption about where on the server
the repositories are located. There 'ought' to be an easier way.
Andy,
I read (skimmed) all your posts, and I'm a little confused but I think
I know where you're going. I'm not sure if you're using Apache to
serve your repositories. If you are, you should check out this:Â
http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/
and this https://help.ubuntu.com/community/Subversion
I recently followed the blog above and got everything setup how I
think you want it. You can control user access to multiple repos in
three ways, the blog explains it all, except one thing. I found that
this is for folder-level control on one repository:
|[/]
@team = r
bob = rw
[/wowapp/trunk]
@team = r
@devteam = rw
brenda = rw|
In my authz control file, multiple repositories are done like this
(note the repo name and colon):
|[repoA:/]
@team = r
bob = rw
[repoB:/]
@team = r
@devteam = rw
brenda = rw|
I also put websvn on it, and use the configuration optionÂ
$config-useAuthenticationFile('/path/to/your/authz/file');
which I found on this stackoverflow QA
http://serverfault.com/questions/13853/how-do-i-restrict-repository-access-via-websvn.Â
http://serverfault.com/questions/13853/how-do-i-restrict-repository-access-via-websvn
WebSVN is now working for me. However http://SERVER/svn is not. I point
my browser to http://SERVER/svnand I get 403 Forbidden.
My dav_svn.conf file includes these lines:
SVNParentPath /Subversion
SVNListParentPath on
Deny from all
Satisfy any
AuthzSVNAccessFile /Subversion/conf/authz
The authz file includes these lines:
[groups]
everybody = andy,louis,spencer
[/]
@everybody = r
[subdoc:/]
andy = rw
[gamble:/]
@everybody = rw
[fred3:/]
spencer = rw
Now AFAIK this should mean that there is a group named everybody which
includes all Subversion users, and that group everybody has read access
to every repository, and user andy has read/write access to 'subdoc',
and group everybody has read/write access to 'gamble', and that only
user spencer has write access to 'fred3'.
I am user andy. I can point my browser to http://SERVER/svn/subdoc; or
even http://SERVER/svn/fred3; with no problem, but not
http://SERVER/svn; -- 403 Forbidden. I think I've done everything that
the documentation says I should do, but it doesn't work.
FYI, I am running Subversion 1.6.12dfsg-4ubuntu2.1.
So how do I give group everybody (but not all users on the server, i.e.
@everybody but not *) read access to $SVNParentPath ?
Re: Subversion: list of respositories
On 07/18/2011 06:27 PM, Nico Kadel-Garcia wrote: On Mon, Jul 18, 2011 at 7:10 AM, Erik Huelsmannehu...@gmail.com wrote: I would think that it looks at SVNParentPath and tries to treat every subdirectory of that as a repository. Not quite. It's not every subdirectory, it's every child directory. Â That means it will not descend into subdirectories of subdirectories, fir example, so they all need to be right there in /var/svn. Also, while symlinks to other locations may be acceptable to the mod_dav_svn module, the repositories need to be accessible to the apache user. This can get adventuresome if you're running svnserve or svn+ssh access without a devault svn+ssh user, used in parallel to Apache. While links are acceptable to mod_dav_svn, they won't appear in the repository listing. Note that you need the SVNListParent On statement in your Apache config to get a listing of the repositories. In 1.7 I've committed a small change to list symlinks to directories which will be part of 1.7. Bye, Erik. Cool, but be careful with those. If you have SELinux enabled and the repositories are elsewhere, for example on a separate disk for bulky repositories, you may need to review your SELinux settings to enable httpd access to the separate location. And oh, dear lord, if someone starts putting symlinks in the reponame/conf/ or reponame/hooks/, can you have adventures. (See http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065dsMessageId=767435, which was only recently fixed and the fix isn't in most public Subversion releases.) SUNNY BEACH! If it's a hard link, editing the file will break the replication. If it's a symbolic link, a hotcopy will drop it. If the symbolic link were copied as a symlink, I need to link it to ../../conf/* instead of /Subversion/conf/* so that my copied symbolic links point into the backup, not into the original. So I have changed my create.php to relative, not abosolute, symlinks, and edited my SVNBackup.sh script to 'cp -p -d' the symlinks from the master to the backup. Thanks for the heads-up.
Worst Error Message?
I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen.
Re: disable security hole in svn+ssh?
On 07/29/2011 02:10 PM, Cooke, Mark wrote: -Original Message- From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] Sent: 29 July 2011 02:27 To: Geoff Hoffman Cc: Nico Kadel-Garcia; users@subversion.apache.org Subject: Re: disable security hole in svn+ssh? snip Apparently, regardless of the protocol, the Subversion library code always checks $SVNParentPath/$Repository/conf/* and obeys svnserve.conf and authz. So I need to learn to use that effectively. snip I am fairly certain that you are wrong about this, only svnserve looks at the svnserve.conf and I believe that you can safely remove this file if you do not use svnserve. In fact the first lines of the default file are: ### This file controls the configuration of the svnserve daemon, if you ### use it to allow access to this repository. (If you only allow ### access through http: and/or file: URLs, then this file is ### irrelevant.) Apache httpd access would not use it at all and will only apply authz if you use the AuthzSVNAccessFile directive... ~ mark c WHOA! Things are getting re-arranged in my mind. Now I think that svnserve has no global authz file at all, and only relies on the individual authz file in the conf subdirectory in each repository, whereas mod_dav_svn relies on a global authz file identified by the AuthzSVNAccessFile in dav_svn.conf. Does mod_dav_svn check the individual authz file in the directory, also? Or does it rely solely on the global authz file? Is this true? My current create.php script replaces $SVNParentPath/REPOSITORY/conf/authz with a symbolic link to $SVNParentPath/conf/authz (which is where my AuthzSVNAccessFile points). This gives the same authorizations across the entire repository collection.
Re: Worst Error Message?
On 07/30/2011 09:31 PM, Stefan Sperling wrote: On Sat, Jul 30, 2011 at 09:15:18PM +0700, Andy Canfield wrote: I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen. Yeah, that's one is bad. I gave a talk about this topic on svnday in May this year: http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf Great PDF. But I would add something at the end: What can Stefan Sperling do? He can post an HTML version of this onto subversion.apache.org so that when users see one of these insane messages they can google for it, and find a rational explanation. Thanks.
Re: SVNParent authz
On 07/29/2011 01:48 PM, Cooke, Mark wrote: -Original Message- From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] Sent: 29 July 2011 05:14 To: users@subversion.apache.org Subject: SVNParent authz I am having a problem with AuthzSVNAccessFile. Consider the case where I have two repositories, R1 and R2 Some users are authorized to examine R1 by going to http://example.com/svn/R1 Other users are authorized to examine R2 by going to http://example.com/svn/R2 But everyone should be able to see the list of repositories by going to http://example.com/svn I can't get that to work. I am having a problem with the mod_dav_svn.conf command: AuthzSVNAccessFile /Subversion/conf/authz If I have AuthzSVNAccessFile turned off (commented out), then all users can see the contents of all repositories. But if I have AuthzSVNAccssFile turned on, then nobody is authorized to see the list of repositories via http://example.com/svn; because I can't figure out how to set authz to give read access to the repository collection but limited access to the individual repositories. Here is my closest guess for authz - [groups] everyone = andy,fred [/] @everyone = r [subdoc:/] andy = rw The [/] section is the part that is incorrect. How can I give everyone read access to http:///example.com/svn; without giving them read access to http://example.com/svn/subdoc; ? Indeed, it seems as if the instant I turn on AuthzSVNAccessFile nobody can read http://example.com/svn; at all. Thank you for your patience. There was a bug relating to authz which meant that users had to have access to the root to see anything, you do not mention which version you are using? Version: 1.6.12dfsg-4ubuntu2.1 Note that you can remove permissions as well as grant them, so something like this should work... [groups] everyone = andy,fred [/] @everyone = r [R1:/] andy = rw fred = [R2:/] andy = fred = rw If that does not work, can you post the relevant bits of your apache conf and also which versions and platforms you are on. For example, I use the following for our windoze based repos: Location /svn/ DAV svn SVNParentPath D:/svn/root/ SVNListParentPath On # restrict access to subversion repository paths... AuthzForceUsernameCase Lower AuthzSVNAccessFile D:/path/to/svn-users.txt /Location ~ mark c Thanks. Built my own web page to do the list of repositories. My page shows megabytes, user and date of last revision, and includes a button to create a new repository. Goes in through PHP, not via SVNListParentPath. Access controlled by Apache not Subversion. Works OK. So we seem to be ready to fly here. Thanks to all.
Access to the SVNParentPath
That's a wonderful thing about computers. Every time I come up with
something that is impossible, I figure out a way to do it.
My current test repository server is named athol. But I can not look
at http://athol/svn;; nobody is allowed to see that.
But, as of now, if I point my browser to http://athol/Subversion;, I
see this:
Subversion on Athol
Repositories
sample3 http://athol/svn/sample3
subdoc http://athol/svn/subdoc
How? Well, the file /Subversion/GSite/index.php is how:
?php
$TITLE = Subversion on Athol;
echo html\n;
echo head\n;
echo title$TITLE/title\n;
echo /head\n;
echo body\n;
echo h1$TITLE/h1\n;
echo h2Repositories/h2\n;
$SVNParentPath = /Subversion;
$RepoList = scandir( $SVNParentPath );
foreach ( $RepoList as $RepoName )
{
$TestRepo = $SVNParentPath . / . $RepoName . /hooks ;
if ( file_exists( $TestRepo ) )
{
echo a href='http://athol/svn/;
. $RepoName
. '
. $RepoName
, /abr /\n;
}
}
closedir( $DIR );
echo /body\n;
echo /html\n;
?
It is, of course, trivlal to use .htpassed to restrict access to this
web page to people who are supposed to be there, and even if someone can
bypass that restriction they only get a list of repositories; The
standard Subversion authz mechanism takes care of access to the
individual repositories.
It is also possible to extend this page with a form you can use to
create a new repository. The form would call up a php page that uses the
system() command to call svnadmin. Ahah! If we move /usr/sbin/svnadmin
into a directory which is only readable by Apache, that makes it
difficult for anyone to use svnadmin at all except through this page.
It's nasty; I love it.
It's compatable; all the standard commands of the form svn ...
http://athol/svn/RepoName; still work as before. That's because access
to the individual repositories is still handled by Subversion.
Maybe one of those wonderful packages like WebSVN could have done that
for me, but I haven't got any of them to work yet. This took me an hour
to get up and running and I can make it do whatever I like.
I am happy! I think I've got it!
Of course, this depends on HTTP or HTTPS access to the production
server, which we're still working on. But it feels good. In the meantime
we can live with svn+ssh.
Thank you all very much.
Re: disable security hole in svn+ssh?
On 07/27/2011 06:47 PM, Nico Kadel-Garcia wrote: On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield andy.canfi...@pimco.mobi wrote: I was trying to get http, svn, and svn+ssh to work. Dude. Pick one. Getting all three to play nicely together is destablilizing. For me, getting any of the four to work is difficult. Here is the status of the various protocols, in order by apparent desirability. The problems are in parentheses. Server:Test Production Network: on LAN on Internet --- 1. HTTPS: (config) (config) 2. HTTP: OK (software mismatch) 3. SVN: OK (port not forwarded) 4. SVN+SSH: (security) (security) Now you see why I'm trying to get any of them working. Every alternative has a problem. I can't get HTTPS to work at all. HTTP on the production server fails due to a software mismatch which we may not be able to fix; the distro from Apple seems to be bad. SVN requires our ISP to change our Router settings. SVN+SSH authentication worksfor me without authorization checking. HERE IT IS USING HTTP: Â Â Â svn infohttp://athol/svn/subdoc Authentication realm:http://athol:80 Athol Subversion Repository Password for 'andy': Path: subdoc URL:http://athol/svn/subdoc Repository Root:http://athol/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) Hold it right there. You're providing password based repository access via HTTP, not HTTPS? Please rethink this unless you *want* the passwords for this repository to be quite insecure and sniffable, especially if you're using normal user login passwords. If HTTP sends passwords in as plain text then yes, HTTPS is better. But I can't get HTTPS to work at all. I get the impression from googling that HTTPS requires a certificate, and I don't have a certificate. If I could generate my own certificate, we could tell our developers Accept this certificate the first time you see it, and after that it will work every time. Also note. For HTTP access from Linux and UNIX systems, the default behavior is to store the password, in cleartext, in $HOME/.subversioon/. *That* is a longstanding security issue that I've been ranting about for *years*. Subversion 1.6.x, very reasonably, now asks for permission before doing that, But if you're using the same password authenticatoin for svn+ssh://,http://,https://, and svn:// based access, you're now writing your password in plain text. locally. svn+ssh:// doesn't recored that plain text password,http:// and htps:// do. HERE IT IS USING SVN: Â Â Â svn info svn://athol/subdoc Authentication realm:svn://athol:3690 Subversion svnserve Password for 'andy': Path: subdoc URL: svn://athol/subdoc Repository Root: svn://athol/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) Again. Unencrypted passwords, unless you're using something like SASL. Do not use this for normal user passwords. Unencrypted passwords stored on the server. We can make the file accessable only by the Apache user. Not ideal, but not bad. If the hacker roots the server we've got no security anyway. HERE IS THE PROBLEM USING SVN+SSH: Â Â Â svn info svn+ssh://athol/data/svn/subdoc The authenticity of host 'athol (192.168.1.113)' can't be established. ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7. Are you sure you want to continue connecting (yes/no)? yes kids@athol's password: Path: subdoc URL: svn+ssh://athol/data/svn/subdoc Repository Root: svn+ssh://athol/data/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) What's 'worse' about it? Well, 'kids' is a valid user name on the server; Which it need not be. The gudebook does not make this clear enough: For users who have normal shell access *anyway*, many sites do use this approach and simply set the repository to be manged with group access to designated users. But in the we don't want people to need shell access to use svn+ssh, you need to set up something like an SSH key on a shared account with forced commands, typically with this kind of URL. svn+ssh://svn@sitename/svn/reponame/ Near as I can tell svn+ssh uses ssh for authentication but it does not seem to do any authorization at all. At that point anybody with an SSH login can do anything; there is no authorization phase for svn+ssh. I am trying to fix that, perhaps using an authz file in every repository, but haven't got it working yet. That svn user can be set to have no valid shell, with its shell set to something like
Re: disable security hole in svn+ssh?
Thank you very much. On 07/28/2011 09:48 PM, Geoff Hoffman wrote: On Thu, Jul 28, 2011 at 7:29 AM, Andy Canfield andy.canfi...@pimco.mobi mailto:andy.canfi...@pimco.mobi wrote: snip Hold it right there. You're providing password based repository access via HTTP, not HTTPS? Please rethink this unless you *want* the passwords for this repository to be quite insecure and sniffable, especially if you're using normal user login passwords. If HTTP sends passwords in as plain text then yes, HTTPS is better. But I can't get HTTPS to work at all. I get the impression from googling that HTTPS requires a certificate, and I don't have a certificate. If I could generate my own certificate, we could tell our developers Accept this certificate the first time you see it, and after that it will work every time. /snip snip So there are actually four protocols that a workstation can use to access a Subversion repository: http, https, svn:, and svn+ssh. Assuming that I pick one, how do I turn the others off? If James Bond can access via https, how can we prevent him from using http and blowing the security? iIf James Bond has an ssh login account on the server, but should not be using Subversion at all, how do we prevent him from using svn+ssh:? How do we prevent him from logging in and using file:? How do we prevent him from logging in and running svnadmin? /snip Wow Andy, you have really put SVN security through the ringer and bring up some really good points. Actually the people in this group are a lot more concerned with security than I am. Here I learned the difference between authentication and authorization. I can trust the standard system alternatives for authentication - ssh, http, https, SSL, whatever. It all winds up being This guy is Charlie. Then the question is, what is Charlie allowed to do? Seems like every protocol uses a different method to do authorization, and that's my ignorance. I'm trying to work out an authorization mechanism that applies regardless of the protocol. In recent years Linux has gone the route that a valid logged-in user can read nearly anything. Can't change it, but can read it. Chalie can read /etc/apache2/mods-enabled/mod_dav_svn.conf. But he can't change it. I can live with that. Because we could have valuable trade secrets in a Subversion repository, I would prefer to limit read access, but if that isn't available so be it. But I am a little horrified that Charlie can create repositories without any authorization at all. I keep comparing Subversion to MySQL. They both store data for you. A repository is like a database. But the average user is not allowed to create databases! Everything you do with MySQL - create, drop, update, select, etc. - goes through the same piece of code; the server. So the MySQL authorization scheme is exactly the same regardless of how you get to the server; it's built into the server, not the protocol. Apparently, regardless of the protocol, the Subversion library code always checks $SVNParentPath/$Repository/conf/* and obeys svnserve.conf and authz. So I need to learn to use that effectively. We're hosting svn behind our firewall on http and so our users have to have a VPN to connect. This of course requires a certain type of security appliance (several hundred bucks at a minimum.) In case it hasn't been obvious, I'm in southeast Asia, definitely third world turf. And this is a startup, with stingy investors. Some of our users have ssh login on the same box running svn but I never thought to secure svnadmin or prevent svn+ssh so I never really thought about it at the level you are doing. You can chroot users [2] into their home dir if you go with svn+ssh... Matt's suggestion to generate ssh keys for everyone is a good idea also (as well as making it simpler to connect in a development workflow) I would think https would be your best bet; you can make a self signed certificate[1] but even an actual SSL isn't that hard to install and only $20/yr from GoDaddy, for example. Yes, HTTPS sounds like the best method. I hate incorrect error messages. I once changed banks because their ATM error messages were wrong. When I try to HTTPS into a serer that's not configured for it FIrefox gives me an error message that says the server response string was too long. That sounds like B.S. to me. Thanks to you, I can make a certificate. You can then detect http protocol with a rewrite rule and redirect to https using mod_rewrite in either the vhost container or .htaccess file. Where would the .htaccess file be for svn+ssh? There's no directory! Have you thought of getting some paid help from, e.g., CollabNet [3]? Maybe well worth it in your case. (Case STUDY more like it!) [1] https://help.ubuntu.com/8.04/serverguide/C/certificates-and-security.html [2] https://help.ubuntu.com/community/BasicChroot
SVNParent authz
I am having a problem with AuthzSVNAccessFile. Consider the case where I have two repositories, R1 and R2 Some users are authorized to examine R1 by going to http://example.com/svn/R1 Other users are authorized to examine R2 by going to http://example.com/svn/R2 But everyone should be able to see the list of repositories by going to http://example.com/svn I can't get that to work. I am having a problem with the mod_dav_svn.conf command: AuthzSVNAccessFile /Subversion/conf/authz If I have AuthzSVNAccessFile turned off (commented out), then all users can see the contents of all repositories. But if I have AuthzSVNAccssFile turned on, then nobody is authorized to see the list of repositories via http://example.com/svn; because I can't figure out how to set authz to give read access to the repository collection but limited access to the individual repositories. Here is my closest guess for authz - [groups] everyone = andy,fred [/] @everyone = r [subdoc:/] andy = rw The [/] section is the part that is incorrect. How can I give everyone read access to http:///example.com/svn; without giving them read access to http://example.com/svn/subdoc; ? Indeed, it seems as if the instant I turn on AuthzSVNAccessFile nobody can read http://example.com/svn; at all. Thank you for your patience.
Web site: checkout or export?
We're doing a web site. The whole site will be under revision control using Subversion. So there are at least three of these: my working copy, the repository, and the working web site. How do I get a working web site? By export? or by checkout? + After we 'svn checkout', If we need to change something on the working web site, we can 'svn commit' to get the changes into the repository. Using 'svn export' we would have to make the changes on a working copy, then commit, then 'svn export' again. + After we 'svn checkout', whenever a new version is in the repository we can 'svn update' and get only the updated files. If we have to use 'svn export' it will give us ALL of the files. - Using 'svn checkout', the working web site will have the subversion control files in the .svn subdirectory, which might be a security hole. Advice?
My Backup Script
For your information, this is my backup script. It produces a zip file that can be tranported to another computer. The zip file unpacks into a repository collection, giving, for each repository, a hotcopy of the repository and a dump of the repository. The hotcopy can be reloaded on a computer with the same characteristics as the original server; the dumps can be loaded onto a different computer. Comments are welcome. #! /bin/bash # requires root access if [ ! `whoami` == root ] then sudo $0 exit fi # controlling parameters SRCE=/data/svn ls -ld $SRCE DEST=/data/svnbackup APACHE_USER=www-data APACHE_GROUP=www-data # Construct a new empty SVNParent repository collection rm -rf $DEST mkdir $DEST chown $APACHE_USER $DEST chgrp $APACHE_GROUP $DEST chmod 0700 $DEST ls -ld $DEST # Get all the names of all the repositories # (Also gets names of any other entry in the SVNParent directory) cd $SRCE ls -d1 * /tmp/SVNBackup.tmp # Process each repository for REPO in `cat /tmp/SVNBackup.tmp` do # some things are not repositories; ignore them if [ -d $SRCE/$REPO ] then # back up this repository echo Backing up $REPO # use hotcopy to get an exact copy # that can be reloaded onto the same system svnadmin hotcopy $SRCE/$REPO $DEST/$REPO # use dump to get an inexact copy # that can be reloaded anywhere svnadmin dump $SRCE/$REPO $DEST/$REPO.dump fi done # Show the contents echo Contents of the backup: ls -ld $DEST/* # zip up the result cd $DEST zip -r -q -y $DEST.zip . # Talk to the user echo Backup is in file $DEST.zip: ls -ld $DEST.zip # The file $DEST.zip can now be transported to another computer.
Re: My Backup Script
On 07/26/2011 04:20 PM, Stefan Sperling wrote:
On Tue, Jul 26, 2011 at 01:33:09PM +0700, Andy Canfield wrote:
For your information, this is my backup script. It produces a zip
file that can be tranported to another computer. The zip file
unpacks into a repository collection, giving, for each repository, a
hotcopy of the repository and a dump of the repository. The hotcopy
can be reloaded on a computer with the same characteristics as the
original server; the dumps can be loaded onto a different computer.
Comments are welcome.
Please also make a backup of every individual revision from the
post-commit hook, like this:
[[[
#!/bin/sh
REPOS=$1
REV=$2
svnadmin dump ${REPOS} -q --incremental --deltas -r ${REV}
/backup/${REV}.dmp
]]]
And make /backup a separate filesystem, preferably on a different host
or some disk storage that runs independently from the host.
In Linux a separate filesystem is often another partition on the hard
disk, and thus not to be trusted too much. For safety an external hard
disk, flushed, should be good enough. No need for an entire other host. Yes?
You will thank me one day when your server's disks die at the wrong moment
e.g. because of power failure or overheating.
In such cases it is possible that not all data has been flushed to disk yet.
The only good data is in the OS buffer cache which the above svnadmin dump
command will get to see. However, even revisions committed several
*minutes* before such a crash can appear corrupted on disk when you reboot.
Thank you very much.
Linux ext3 filesystems used to be pretty much immune to unflushed
buffers; anything older than 5 seconds would be written to disk. But
now, with ext4, there's no guarantee, and I've seen the thing have
unflushed buffers after one minute. And I'm not supposed to be able to
see that!
Of course, even Linux isn't immune to a burned-out hard disk controller.
As for overheading, I can't help but joke that perhaps the overheading
was caused by all the backups you were doing? Ha ha. Of course not!
I've seen this happening (on Windows, with NTFS -- lots of damage;
but other operating systems aren't immune to this either).
We could tell that the buffer cache data was good because there were
multiple corrupted revision files (one repository had more than 20
broken revisions), each with random junk in some parts, and all broken
parts were 512 byte blocks, i.e. disk sectors. But in the parts that
were not broken they referred to each other in ways that made perfect
sense. So before the crash they were all OK. There were no backups so
we had to manually repair the revisions (this requires intricate
knowledge about the revision file format and takes time...)
When this happens you have an unusable repository. Anything referring
to the broken revisions will fail (commit, diff, update, ...).
Assuming the incremental dumps weren't destroyed in the catastrophe
you can load the incremental dumps on top of your last full backup and
get to a good state that is very close to the point in time when the
crash happened.
Without the incremental dumps you'll have the last full backup.
But anything committed since could be lost forever.
Anything commited since the last full backup would be lost only if no
longer exists in the developer's working copy. The size of the mess
depends on how many commits you lost. Ten per developer per day, and 20
developer, is a massive headache. Two per developer per week, and three
developers, is not a catastrophe.
As I understand Subversion,
[a] The server has no idea who has a working copy.
[b] The checkout builds a working copy on the workstation from the
server's repository.
[c] What is on the developers hard disk is a working copy.
[d] What is on the developer's hard disk continues to be a working copy,
even after a commit.
[e] If the developer tries to make revisions to his working copy six
months after his last commit, then tries to commit, he's going to have a
major mess on his hands trying to reconcile things. The working copy is
still a valid working copy.
[f] Unlike a lock, which he grabs and then releases, he never gives up
his working copy; it is valid perpetually.
[g] The usual way a working copy goes away is with the rm -rf command.
Thanks for the great information!
Re: My Backup Script
On 07/27/2011 01:34 AM, Nico Kadel-Garcia wrote: On Tue, Jul 26, 2011 at 2:33 AM, Andy Canfieldandy.canfi...@pimco.mobi wrote: For your information, this is my backup script. It produces a zip file that can be tranported to another computer. The zip file unpacks into a repository collection, giving, for each repository, a hotcopy of the repository and a dump of the repository. The hotcopy can be reloaded on a computer with the same characteristics as the original server; the dumps can be loaded onto a different computer. Comments are welcome. Andy, can we love you to pieces for giving us a new admin to educate in subtleties? Sure! I'm good at being ignorant. FYI I have a BS in Computer Science about 1970 and an MS in Operations Research in 1972, worked in Silicon Valley until I moved to Thailand in 1990. So although I am not stupid, I can be very ignorant. And also the IT environment here is quite different. For example, MySQL can sync databases if you've got a 100Mbps link. Ha ha. I invented a way to sync two MySQL databases hourly over an unreliable link that ran at about modem speeds. I can remember making a driver climb a flagpole to make a cell phone call because the signal didn't reach the ground. To this day we run portable computers out in the field and communicate via floppynet. In this region hardware costs more than people, and software often costs nothing. #! /bin/bash # requires root access if [ ! `whoami` == root ] then sudo $0 exit fi # controlling parameters SRCE=/data/svn ls -ld $SRCE DEST=/data/svnbackup APACHE_USER=www-data APACHE_GROUP=www-data Unless the repository is only readable owned by root, this should *NOT* run as root. Seriously. Never do things as the root user that you don't have to. If the repository owner is svn or www-data as you've described previously, execute this as the relevant repository owner. There are reasonable justifications for running it as root: [1] Other maintenance scripts must be run as root, and this puts all maintenance in a central pool. My maintenance scripts are crontab jobs of the form /root/bin/TaskName.job which runs /root/bin/TaskName.sh and pipes all stderr and stdout to /root/TaskName.out. Thus I can skim /root/*.out and have all the job status information at my fingertips. [2] For some tasks, /root/bin/TaskName.job is also responsible for appending /root/TaskName.out to /root/TaskName.all so that I can see earlier outputs. There is a job that erases /root/*.all the first of every month. [3] I have heard for a long time never run GUI as root. None of these maintenance scripts are GUI. [4] There are many failure modes that will only arise if it is run as non-root. For example, if run as root, the command rm -rf /data/svnbackup will absolutely, for sure, get rid of any existing /data/svnbackup that exists, whoever it is owned by, whatever junk is inside it. # Construct a new empty SVNParent repository collection rm -rf $DEST mkdir $DEST chown $APACHE_USER $DEST chgrp $APACHE_GROUP $DEST chmod 0700 $DEST ls -ld $DEST And do. what? You've not actually confirmed that this has succeded unless you do something if these bits fail. Many of your comments seem to imply that this script has not been tested. Of course it's been tested already, and in any production environment it will be tested again. And if stdout and stderr are piped to /root/SVNBackup.out then I can check that output text reasonably often and see that it is still running. In this case I would check it daily for a week, weekly for a month or two, yearly forever, and every time somebody creates a new repository. Also, by the standards of this part of the world, losing a day's work is not a catastrophe. Most people can remember what they did, and do it again, and it probably only takes a half-day to redo. # Get all the names of all the repositories # (Also gets names of any other entry in the SVNParent directory) cd $SRCE ls -d1 */tmp/SVNBackup.tmp And *HERE* is where you start becoming a dead man id mkdir $DEST failed. I believe that it works in your current environment, but if the parent of $DEST does not exist, you're now officially in deep danger executing these operations in whatever directory the script was run from. As noted above, $DEST is /data/svnbackup. The parent of $DEST is /data. /data is a partition on the server. If that partition is gone, that's a failure that we're talking about recovering from. # Process each repository for REPO in `cat /tmp/SVNBackup.tmp` And again you're in trouble. If any of the repositories have whitespace in their names, or funky EOL characters, the individual words will be parsed as individual arguments. This is Linux. Anyone who creates a repository with white space in the name gets shot. do # some things are not repositories; ignore them if [ -d $SRCE/$REPO ] Here is a likely bug in the script. I treat every subdirectory of the SVNParent repository collection as
disable security hole in svn+ssh?
I was trying to get http, svn, and svn+ssh to work. HERE IT IS USING HTTP: *svn info http://athol/svn/subdoc Authentication realm: http://athol:80 Athol Subversion Repository Password for 'andy': Path: subdoc URL: http://athol/svn/subdoc Repository Root: http://athol/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)* HERE IT IS USING SVN: *svn info svn://athol/subdoc Authentication realm: svn://athol:3690 Subversion svnserve Password for 'andy': Path: subdoc URL: svn://athol/subdoc Repository Root: svn://athol/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)* HERE IS THE PROBLEM USING SVN+SSH: *svn info svn+ssh://athol/data/svn/subdoc The authenticity of host 'athol (192.168.1.113)' can't be established. ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7. Are you sure you want to continue connecting (yes/no)? yes kids@athol's password: Path: subdoc URL: svn+ssh://athol/data/svn/subdoc Repository Root: svn+ssh://athol/data/svn/subdoc Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 Revision: 4 Node Kind: directory Last Changed Author: andy Last Changed Rev: 4 Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) * What's 'worse' about it? Well, 'kids' is a valid user name on the server; 'kids' can ssh into the server. But 'kids' has no authorization to access any Subversion repository in any way. To me this means that svn+ssh is a GIGANTIC security hole. Consider these commands: *ssh k...@example.com rm -rf /data/svn/subdoc* They do nothing; user 'kids' has no right to see anything inside the /data/svn directory, which is owned by www-data and readable (and writable) only by that user. But consider these commands: *mkdir t cd t svn checkout svn+ssh://example.com/data/svn/subdoc svn delete * **svn commit* These will post a revision deleting everything in the repository. And this second set of commands relies only on 'kids' being able to log in to the server; they need not have any permission to do anything in Subversion! Is there any way to modify things on the server to disable the svn+ssh: protocol without disabling either standard ssh or the svn: protocol?
Re: Subversion: existing users
On 07/24/2011 03:25 AM, Ryan Schmidt wrote: On Jul 23, 2011, at 03:27, Andy Canfield wrote: On 07/21/2011 07:27 PM, Cooke, Mark wrote: I don't use *nix much but shouldn't that be `chown -R ...`? Nope, the format of that command on Linux is chown username.groupname fileselector Generally chown has to be run as root in order to be allowed to change the file owner. The command on OS X is nearly the same but the user and group are separated by a colon, not a period. -R means recursive, and yes, you probably did want to have used that option so that all items in the directory, and not just the directory itself, have their ownership corrected. You're right; -R means recursive. I have never used 'chown -R'. In this case I did not need it because I applied the chown immediately after creating the SVNParent. Here is the latest version: *APACHE_USER=www-data APACHE_GROUP=www.data SVNPARENT=/data/svn sudo mkdir $SVNPARENT **sudo **chown $APACHE_USER $SVNPARENT **sudo **chgrp $APACHE_GROUP $SVNPARENT sudo chmod 0700 $SVNPARENT *
Re: svnadmin failure on nearly identical system
On 07/22/2011 10:20 AM, Ryan Schmidt wrote: On Jul 21, 2011, at 22:09, Andy Canfield wrote: I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I have the same system installed on my desktop computer named Athol (I had a lot of trouble getting that hardware to work). I have installed the Ubuntu Subversion packages on each; namely subversion libapache2-svn libgirepository-1.0-1 In both cases the SVNParentPath is /data/svn and that directory is owned by www-data: drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn Here is the critical command: sudo -u www-data svnadmin create /data/svn/boofar On Lenny the command works, silently. On Athol I get this message: svnadmin: error while loading shared libraries: libsvn_repos-1.so.0: cannot open shared object file: No such file or directory Apparently svnadmin cannot find something, but I don't know what it can't find. In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to: -rw-r--r-- 1 root root 153700 2011-06-05 22:48 /usr/lib/libsvn_repos-1.so.1.0.0 I Googled for that error message and somebody had a problem with the home directory locations. The implication was that for some reason a Subversion distribution hard-codes the name of the home directory parent path (e.g. /home). No problem with my home directories; the arrangement is identical. On both machines my home directory is /data/andy and /home/andy is a symbolic link to /data/andy. So any idea why svnadmin runs OK on one machine and fails on the other? Is there perhaps a second (older) copy of Subversion or its libraries installed, perhaps provided by your distribution? If so, try uninstalling that. Nope; I installed subversion on Athol yesterday, and I run apt-get upgrade frequently. UPDATE - ANOTHER TEST I used 'tar' to move /data/svn/sample3 - an existing repository - from Lenny to Athol. Now I can point my browser to http://athol/svn/sample3 and see the usual status screen. For command on Lenny: *svn info http://localhost/svn/sample3* The response is: *Authentication realm: http://localhost:80 Lenny Subversion Repository Password for 'andy': Path: sample3 URL: http://localhost/svn/sample3 Repository Root: http://localhost/svn/sample3 Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c Revision: 0 Node Kind: directory Last Changed Rev: 0 Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011) *FOr this command on Lenny: *svn info http://athol/svn/sample3* The response is: *Authentication realm: http://athol:80 Athol Subversion Repository Password for 'andy': Path: sample3 URL: http://athol/svn/sample3 Repository Root: http://athol/svn/sample3 Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c Revision: 0 Node Kind: directory Last Changed Rev: 0 Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)* But this command on Athol: *svn info http://localhost/svn/sample3 *gives this error result: *vn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory* *So the problem is in the client, not on the apache server. And both svnadmin and svn show the same problem.* = FOUND IT! God knows where it came from, but there was a set of svn* programs in /usr/local/bin. Erased them all and now it works. Thank you very much; this counts as success for today.
Re: Subversion access control / Linux users etc.
Thank you very much. On 07/22/2011 02:36 AM, Ryan Schmidt wrote: On Jul 21, 2011, at 06:54, Andy Canfield wrote: 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. Looks normal to me. It's showing you there is a repository, and it is empty. So the browser access mechanism has no commands to control a repository, only to describe it? It shows you the contents of the HEAD of the repository. There are also URL parameters you can add to look at previous revisions of files. But that's about it. If you want more detailed views into your repository, install a tool dedicated to that purpose, like WebSVN, Trac or ViewVC. http://www.websvn.info/ http://trac.edgewall.org/ http://www.viewvc.org/ Thank you for the three leads. I have installed all three from Ubuntu and will try them out. Logically this might make sense; however I would expect that http://localhost/svn would be capable of listing the repositories It is. You need to add SVNListParentPath On to your httpd configuration. Just as directory listings are off in Apache by default for security reasons, so showing a list of repositories is off by default in Subversion. and creating new repositories. Sorry, that's not a feature of the mod_dav_svn web interface. Administration functions, like creating and deleting repositories and users, is expected to be done by the sysadmin on the command line of the server. If you want a web interface for that, there are other administration-oriented web interfaces you could install, like SVNManager. http://svnmanager.org/ For some strange reason SVNManager is not available through the Ubuntu Linux 11.04 distribution interface. So I'll hold off on that. Thanks for the leads.
Re: Subversion: existing users
On 07/21/2011 07:27 PM, Cooke, Mark wrote: -Original Message- From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] Sent: 21 July 2011 13:19 To: nka...@gmail.com Cc: users@subversion.apache.org Subject: Re: Subversion: existing users On 07/21/2011 05:55 PM, Andy Levy wrote: On Thu, Jul 21, 2011 at 06:12, Andy Canfield andy.canfi...@pimco.mobi mailto:andy.canfi...@pimco.mobi wrote: ADDENDUM ... I used root to create the /data/svn directory. Then, anticpiating problems, I did a chmod to make it writable to all. Giving global write permission will lead to problems as well. Different problems, but problems nonetheless. Later I ran svnadmin create /data/svn/sample and it created an entire repository directory tree under /data/svn. I don't remember but I probably ran it as root. I just now noticed that /data/svn/sample and all the sub-directories and files therein are owned by root and, usually, writable only by root. This is probably going to cause problems for Apache / mod_dav_svn which, of course, runs as the 'apache user' (www-data) instead of root. Where did I go wrong? The manual talks about commands but does not seem to talk about what user is executing the command. Do I have to run svnadmin as www-data? Is there a way to create a repository using my browser? Your repository directory (the one you created with svnadmin create) should be owned by www-data (or whatever account your server process executes under). It doesn't matter whether you run svnadmin create as that user, or run it as another user and then change ownership. OK, restart again. The new commands to create the RepositoryParent directory are: mkdir /data/svn sudo chown www-data.www-data svn I don't use *nix much but shouldn't that be `chown -R ...`? Nope, the format of that command on Linux is chown username.groupname fileselector Generally chown has to be run as root in order to be allowed to change the file owner. The command on OS X is nearly the same but the user and group are separated by a colon, not a period. This results in drwxr-xr-x 3 www-data www-data 4096 2011-07-21 19:01 /data/svn Here is the command I used to create a repository: sudo -u www-data svnadmin create /data/svn/sample3 Now we have drwxr-xr-x 6 www-data www-data 4096 2011-07-21 19:01 /data/svn/sample3 -rw-r--r-- 1 www-data www-data 229 2011-07-21 19:01 /data/svn/sample3/README.txt etc. When I point my browser to http://localhost/svn/sample3 I still get this short page: sample3 - Revision 0: / Powered by Subversion version 1.6.12 (r955767). so I still suspect that the browser interface is incapable of performing any action, including creating a repository, and is also incapable of giving me a list of repositories. It WILL give you a list of reporsitories _under_a_parent_root_ IF you configure it correctly. Of course this tends to be easier (and less secure?) under windoze... As has been mentioned in other posts, you need to give mod_dav_svn TWO directives: SVNParentPath D:/svn/ SVNListParentPath On What are you expecting the browser interface to give you? It provides a fairly simple, read-only interface to the repositories it is configured to serve. There are tools (ViewVC etc) that provide more functionality but general operation is NOT through the browser but a subversion client that happens to use https (etc) as the communication patheway. (I notice Andy Levy has addressed this point better than I) ~ mark c I would like to comment here that I've given up the idea of automatically giving repository access users with an existing login. While it's not a problem now, it is quite possible that in the future we'll have people with server logins but we don't wnat those people to be able to see work in progress on advanced projects. Using the specific http-based mechanisms we can keep advanced research projects away from the eyes of people who shouldn't see it. Automatically granting access to a user just because he has a login account was a bad idea. Thank you all.
Re: Subversion access control
Thank you very much
On 07/20/2011 10:27 PM, Geoff Hoffman wrote:
Andy,
I thought you were off Apache and onto svnserve. Anyway, I sent you
this info last week - maybe you missed it. It is pasted again below.
I will grant to you that it is tricky to set up. The david winter blog
post below spells it out perfectly... for a single repo setup,
multiple users. For multi-user, multi-repo setup see my pasted config
files below. One thing to note that is confusing is that if your repos
are at /subversion/repos/repo1 your Location /svn stays the same.
The /svn bit there is what appears in the URL address bar, its not a
filesystem path.
I have 10 repositories, project1 through project10, physically located
on Ubuntu filesystem at
/svn/project1
/svn/project2
...
/svn/project10
Here is my /etc/apache2/mods-available/dav_svn.conf (the comments come
with the file. This was installed using apt-get on Ubuntu 10.04 LTS.)
Location /svn
# Uncomment this to enable the repository
DAV svn
# Set this to the path to your repository
#SVNPath /svn
# Alternatively, use SVNParentPath if you have multiple repositories
under
# under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2,
...).
# You need either SVNPath and SVNParentPath, but not both.
SVNParentPath /svn
SVNListParentPath on
This was the line missing from my config file; It allows me to see the
overall pictures. Thanks!
# From
http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
#Order deny,allow
Deny from all
Satisfy any
Makes sense. I changed mine to fit yours.
# Access control is done at 3 levels: (1) Apache authentication, via
# any of several methods. A Basic Auth section is commented out
# below. (2) Apache Limit and LimitExcept, also commented out
# below. (3) mod_authz_svn is a svn-specific authorization module
# which offers fine-grained read/write access control for paths
# within a repository. (The first two layers are coarse-grained; you
# can only enable/disable access to an entire repository.) Note that
# mod_authz_svn is noticeably slower than the other two layers, so if
# you don't need the fine-grained control, don't configure it.
# Basic Authentication is repository-wide. It is not secure unless
# you are using https. See the 'htpasswd' command to create and
# manage the password file - and the documentation for the
# 'auth_basic' and 'authn_file' modules, which you will need for this
# (enable them with 'a2enmod').
AuthType Basic
AuthName Subversion Repository
AuthUserFile /etc/apache2/dav_svn.passwd
# To enable authorization via mod_authz_svn
AuthzSVNAccessFile /etc/apache2/dav_svn.authz
# The following three lines allow anonymous read, but make
# committers authenticate themselves. It requires the 'authz_user'
# module (enable it with 'a2enmod').
#LimitExcept GET PROPFIND OPTIONS REPORT
Require valid-user
#/LimitExcept
/Location
Now, here is my /etc/apache2/dav_svn.authz file.
[groups]
group1 = usera, userb, userc, userd, usere
group2 = userc, userb
group3 = userf, userg
group4 = usera, userb, userc, userd, usere, userf
group5 = userh
[/]
@group1 = rw
@group2 =
@group3 =
@group4 =
@group5 =
[project1:/]
@group1 = rw
[project2:/]
@group1 = rw
userg = rw
userf = rw
[project4:/]
@group1 = rw
[project5:/]
@group11 = rw
[project6:/]
@group1 = rw
@group5 = rw
[project7:/]
@group1 = rw
[project8:/]
@group1 = rw
[project9:/]
@group1 = rw
[project10:/]
@group1 = rw
@group4 = rw
I notice that you don't have any entries that read ... = r; everyone
who can read can write also. No need?
There is no need to send you the dav_svn.passwd - it merely lists
usera through userh with their hashed password. You use the htpasswd
program to set your users up.
Here is the email I sent before...
I read (skimmed) all your posts, and I'm a little confused but I think
I know where you're going. I'm not sure if you're using Apache to
serve your repositories. If you are, you should check out this:
http://davidwinter.me/articles/2006/03/03/access-control-for-subversion-with-apache2-and-authz/
and this https://help.ubuntu.com/community/Subversion
I recently followed the blog above and got everything setup how I
think you want it. You can control user access to multiple repos in
three ways, the blog explains it all, except one thing. I found that
this is for folder-level control on one repository:
|[/]
@team = r
bob = rw
[/wowapp/trunk]
@team = r
@devteam = rw
brenda = rw|
In my authz control file, multiple repositories are done like this
(note the repo name and colon):
|[repoA:/]
@team = r
bob = rw
[repoB:/]
@team = r
@devteam = rw
brenda = rw|
I also put websvn on it, and use the configuration option
Looks interesting; I installed it. Lots of configuration to do; will do
later.
$config-useAuthenticationFile('/path/to/your/authz/file');
which I found
Re: Subversion: existing users
On 07/21/2011 09:33 PM, Nico Kadel-Garcia wrote: On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfieldandy.canfi...@pimco.mobi wrote: ADDENDUM ... I used root to create the /data/svn directory. Then, anticpiating problems, I did a chmod to make it writable to all. Later I ran svnadmin create /data/svn/sample and it created an entire repository directory tree under /data/svn. I don't remember but I probably ran it as root. I just now noticed that /data/svn/sample and all the sub-directories and files therein are owned by root and, usually, writable only by root. This is probably going to cause problems for Apache / mod_dav_svn which, of course, runs as the 'apache user' (www-data) instead of root. Where did I go wrong? The manual talks about commands but does not seem to talk about what user is executing the command. Do I have to run svnadmin as www-data? Is there a way to create a repository using my browser? Welcome to sys-admin hell, the documentation is true, but not complete world that I've spent so many years in. The connections between different pieces of information that are obvious to someone who's been through similar issues in the past are not obvious to a an intelligent but new person like yourself. Yes. But don't forget The documentation was true, then, but may not be true any more. I once googled for how to install Tomcat and the first web page I hit said that I had to recompile Apache myself. Written in 2002. It goes back to what are you trying to achieve. If you're setting up an svn+ssh repository with direct user logins, various components need to be owned with write permissions for those users. This is typically done by putting users in a particular authorized group, such as project1 for the project1 repository at /var/svn/project1. The configuration files, such as /var/svn/project1/conf/ and /var/svn/project1/scripts, can be owned by any user or group, as long as the connecting user has appropriate read or execute access. If you're setting it up for web access, it needs to have the writable /var/svn/project1/db directory writable by whatever user runs the HTTP daemon, typically apache or www-data on modern Linux systems. If you're setting up both web access and svn+ssh, your life becomes more interesting and we could review that. It's tricky to do well. I got that impression, after lots of agony over user group permissions on the repositories. /var/svn/project1/db directory needs write access for the users. All of them. When you use the kind of shared permission access you've selected based on active local logins, you've given up control of that directory to all the local users. It is theoretically possible to set up cron job that scans that directory and resets ownership to a local svn user of all successfully loaded revisions, and set the directory permissions to 1777 to prevent users deleting each other's revisions, but without such chicanery you cannot defend this file in that kind of shard access setup. My current impression is that the /var/syn/project/... directories need write access to whatever system user is running the service; either apache/mod_dav_svn.so or svnserve. Hell breaks loose when you have to use direct access to use svnadmin. Since websvn is said to work, and websvn runs under Apache, it should be happy with the same system user ownership as apache/mod_dav_svn.so likes. This is also where you get into trouble with your ideal of locking down individual files. Individual working copy files aren't stored in the database, they are *assembled* from the list of revisions involved in modifying that file throughout that file's history. This is partly why the most viable Subversion models of preventing individual file or difectory modifications are all in the pre-commit stages, not in the database structure itself. And unfortunately, this sort of chicanery is not replicated for backups: if you run svnadmin hotcopy to copy your repository, it will not preserve the funky ownerships, and you'll need to deal with it again. Andy, it really sounds like you're getting caught up in the small details. What *must* you have? Access for everyone with a valid system login, or a designated list of users? Can your people use SSH keys, which can seriously simplify ownership issues, and will HTTPS access serve their needs? The group I'm with right now only has three members, and this is the server for our organization, and so everyone happens to have a login on that server. Obviously a server tends to have lots of different users, doing lots of different things. A centralized login authentication system is desirable. And for my experience, on a single machine server, that's the standard OS user login. It works for ssh and sftp and ftp. No need to memorize three passwords, no need to set up three different authentication files. Unfortunately http and MySQL don't authenticate that way, so we have to set up parallel systems. 'htpasswd' is just another
Limited Access Repository
I changed my repository parent so that it is not readable, not writable, not searchable by anyone except the owner, which is www-data (the user that Apache runs as) - *drwx-- 2 www-data www-data 4096 2011-07-22 15:45 /data/svn* I figure that will keep other users away from the contents. Only root and Apache can see the contents and therefore do anything with it.
Setuid
Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much.
Re: Setuid
On 07/22/2011 11:29 PM, David Chapman wrote: On 7/22/2011 8:38 AM, Andy Canfield wrote: Had what seems to be a bright idea. It is a bright idea for a Subversion server on Linux or OS X; AFAIK this idea has no relevance to Windows: Take note of the user and group that Apache runs as. Call this combination APACHE, meaning APACHE_USER and APACHE_GROUP. Whatever mod_dav_svn does to any repository will be done by APACHE. Whatever WebSVN does to any repository will be done by APACHE. If I set the svnserve program to be owned by APACHE, and setuid and setgid, then whatever svnserve does to any repository will also be done by APACHE. Only root, or the APACHE user, can make this change to the svnserve program binary. If I set the svnadmin program to be owned by APACHE, and setuid and setgid, then whatever svnadmin does to any repository will also be done by APACHE. If I set the svnlook program to be owned by APACHE, and setuid and setgid, then whatever svnlook does to any repository will be done by APACHE. So the three access paths - http:, svn:, and direct - will all operate using the same user and group. You don't want to do this to any program, such as 'svn', which relies on user authentication, since it needs to know the actual user that is running the program. But any program which operates directly on the repository can be set this way and that ensures that the repository is always manipulated, at a low level, by the same user all the time. So a post-installation setup would include: *sudo bash cd /usr/bin chown APACHE_USER svnadmin svnlook svnserve chgrp APACHE_GROUP svnadmin svnlook svnserve* This idea also allows me to make the the respository itself accessable only by APACHE. This ensures that the repository can only be manipulated by Subversion code itself (or by root): *sudo bash mkdir /var/svn chown APACHE_USER**/var/svn* *chgrp APACHE_GROUP**/var/svn* *chmod 0700 /var/svn* If I also do this: *sudo bash rm /usr/bin/svnadmin* then all repository creation would have to be done via something like WebSVN, which I assume requires authentication. How does that sound to you guys? Where are the flaws in this idea? Thank you very much. It prevents privately owned and managed repositories. Normally, individual users can set up their own repositories for their own (personal) projects or files. If you are planning to do this on a server that you wish to lock down, then I see no reason why it would cause problems, but if users can login and do other work on this machine, you are constraining them. Ah, I see a lack of terminology here. Consider the respository located at /var/svn/sample, the repository named sample and accessed through the browser as http://example.com/svn/sample;. What is the name for /var/svn? Is it a Repository Collection? The config entry is SVNParentPath, so let's call it the SVNParent. If you have an account on that server computer, and you don't have root access, and you want your own pesonal repository collection, then even today you can't use http: access to it, either because you can't configure Apache or because Apache is already configured for the standard SVNParent. The suggestion would make the SVNParent accessable only through the standard software, never directly. Any user could create his own respository, but it would be in the standard SVNParent. If /usr/bin/svnserve is owned by www-data (APACHE) and setuid, then you can't run /usr/bin/svnserve to access your own personal SVNParent. It can access your own repository in the standard SVNParent, but not your own SVNParent. However, it appears that it can be done using two Linux commands: *copy /usr/bin/svnserve ~/bin/svnserve copy /usr/bin/svnadmin ~/bin/svnadmin* The copies are owned by you and are no longer setuid. So you can run ~/bin/svnserve and it will operate under your user name and manage your own personal SVNParent. (I have not tested this yet, but it should work). On Fri, 22 Jul 2011 13:24:55 -0400 Nico Kadel-Garcia wrote: Sounds dangerous and untested. svnserve, for example, is not designed to be run suid. It's not necessarily handling UID versus EUID correctly for this. (It might, it's not tested.) That sounds like a serious concern; no way to be sure. But for me it would be worth the experiment.
Re: Subversion: existing users
ADDENDUM ... I used root to create the /data/svn directory. Then, anticpiating problems, I did a chmod to make it writable to all. Later I ran svnadmin create /data/svn/sample and it created an entire repository directory tree under /data/svn. I don't remember but I probably ran it as root. I just now noticed that /data/svn/sample and all the sub-directories and files therein are owned by root and, usually, writable only by root. This is probably going to cause problems for Apache / mod_dav_svn which, of course, runs as the 'apache user' (www-data) instead of root. Where did I go wrong? The manual talks about commands but does not seem to talk about what user is executing the command. Do I have to run svnadmin as www-data? Is there a way to create a repository using my browser?
Re: Subversion access control / Linux users etc.
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 DONT 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.
Re: Subversion: existing users
On 07/21/2011 05:55 PM, Andy Levy wrote: On Thu, Jul 21, 2011 at 06:12, Andy Canfieldandy.canfi...@pimco.mobi wrote: ADDENDUM ... I used root to create the /data/svn directory. Then, anticpiating problems, I did a chmod to make it writable to all. Giving global write permission will lead to problems as well. Different problems, but problems nonetheless. Later I ran svnadmin create /data/svn/sample and it created an entire repository directory tree under /data/svn. I don't remember but I probably ran it as root. I just now noticed that /data/svn/sample and all the sub-directories and files therein are owned by root and, usually, writable only by root. This is probably going to cause problems for Apache / mod_dav_svn which, of course, runs as the 'apache user' (www-data) instead of root. Where did I go wrong? The manual talks about commands but does not seem to talk about what user is executing the command. Do I have to run svnadmin as www-data? Is there a way to create a repository using my browser? Your repository directory (the one you created with svnadmin create) should be owned by www-data (or whatever account your server process executes under). It doesn't matter whether you run svnadmin create as that user, or run it as another user and then change ownership. OK, restart again. The new commands to create the RepositoryParent directory are: *mkdir /data/svn sudo chown www-data.www-data svn* This results in *drwxr-xr-x 3 www-data www-data 4096 2011-07-21 19:01 /data/svn* Here is the command I used to create a repository: *sudo -u www-data svnadmin create /data/svn/sample3* Now we have *drwxr-xr-x 6 www-data www-data 4096 2011-07-21 19:01 /data/svn/sample3 -rw-r--r-- 1 www-data www-data 229 2011-07-21 19:01 /data/svn/sample3/README.txt* etc. When I point my browser to http://localhost/svn/sample3 I still get this short page: *sample3 - Revision 0: / Powered by Subversion version 1.6.12 (r955767).* so I still suspect that the browser interface is incapable of performing any action, including creating a repository, and is also incapable of giving me a list of repositories.
Subversion user problem?
I ran into a problem with a web site I am developing under Drupal; a problem related to user. And I suspect that the same problem arises witn Subversion. On my local copy of that site, sometimes the PHP code creates a directory and puts files into that directory. The directory had standard permissions - readable by all but writable only by owner. But that directory is owned by www-data because apache/PHP created the directory. But when I zip it up, upload it to the server in Hong Kong, and unzip it, all directories are owned by the user on the server who unzipped the directory. The permissions were preserved; still readable by all but writable only by the owner. But the owner was no longer the Apache user, it was the user who unzipped the directory. I had to invent two shell scripts; one to run on my computer finding all the directories owned by Apache on my machine, and the second run on the server making all those directories writable by all. I suspect that if I were using Subversion I would still have that problem. I do not remember seeing anything in the manual about preserving directory and file attributes, such as readable by all and writable by all. I do not remember seeing anything in the manual about directory owners. I saw no warning, I saw no assurance. But, then again, I haven't finished the second manual yet. Maybe that's covered farther back in the book. So does Subversion preserve directory attributes?
svnadmin failure on nearly identical system
I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I have the same system installed on my desktop computer named Athol (I had a lot of trouble getting that hardware to work). I have installed the Ubuntu Subversion packages on each; namely subversion libapache2-svn libgirepository-1.0-1 In both cases the SVNParentPath is /data/svn and that directory is owned by www-data: *drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn* Here is the critical command: *sudo -u www-data svnadmin create /data/svn/boofar* On Lenny the command works, silently. On Athol I get this message: * svnadmin: error while loading shared libraries: libsvn_repos-1.so.0: cannot open shared object file: No such file or directory* Apparently svnadmin cannot find something, but I don't know what it can't find. In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to: *-rw-r--r-- 1 root root 153700 2011-06-05 22:48 /usr/lib/libsvn_repos-1.so.1.0.0* I Googled for that error message and somebody had a problem with the home directory locations. The implication was that for some reason a Subversion distribution hard-codes the name of the home directory parent path (e.g. /home). No problem with my home directories; the arrangement is identical. On both machines my home directory is /data/andy and /home/andy is a symbolic link to /data/andy. So any idea why svnadmin runs OK on one machine and fails on the other?
Re: svnadmin failure on nearly identical system
On 07/22/2011 10:20 AM, Ryan Schmidt wrote: On Jul 21, 2011, at 22:09, Andy Canfield wrote: I have Ubuntu Linux 10.4 installed on my notebook computer named Lenny. I have the same system installed on my desktop computer named Athol (I had a lot of trouble getting that hardware to work). I have installed the Ubuntu Subversion packages on each; namely subversion libapache2-svn libgirepository-1.0-1 In both cases the SVNParentPath is /data/svn and that directory is owned by www-data: drwxr-xr-x 5 www-data www-data 4096 2011-07-22 09:16 /data/svn Here is the critical command: sudo -u www-data svnadmin create /data/svn/boofar On Lenny the command works, silently. On Athol I get this message: svnadmin: error while loading shared libraries: libsvn_repos-1.so.0: cannot open shared object file: No such file or directory Apparently svnadmin cannot find something, but I don't know what it can't find. In both cases /usr/lib/libsvn_repos-1.so.1 is a symoblic link to: -rw-r--r-- 1 root root 153700 2011-06-05 22:48 /usr/lib/libsvn_repos-1.so.1.0.0 I Googled for that error message and somebody had a problem with the home directory locations. The implication was that for some reason a Subversion distribution hard-codes the name of the home directory parent path (e.g. /home). No problem with my home directories; the arrangement is identical. On both machines my home directory is /data/andy and /home/andy is a symbolic link to /data/andy. So any idea why svnadmin runs OK on one machine and fails on the other? Is there perhaps a second (older) copy of Subversion or its libraries installed, perhaps provided by your distribution? If so, try uninstalling that. Nope; I installed subversion on Athol yesterday, and I run apt-get upgrade frequently. UPDATE - ANOTHER TEST I used 'tar' to move /data/svn/sample3 - an existing repository - from Lenny to Athol. Now I can point my browser to http://athol/svn/sample3 and see the usual status screen. For command on Lenny: *svn info http://localhost/svn/sample3* The response is: *Authentication realm: http://localhost:80 Lenny Subversion Repository Password for 'andy': Path: sample3 URL: http://localhost/svn/sample3 Repository Root: http://localhost/svn/sample3 Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c Revision: 0 Node Kind: directory Last Changed Rev: 0 Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011) *FOr this command on Lenny: *svn info http://athol/svn/sample3* The response is: *Authentication realm: http://athol:80 Athol Subversion Repository Password for 'andy': Path: sample3 URL: http://athol/svn/sample3 Repository Root: http://athol/svn/sample3 Repository UUID: 4597fcf2-fe51-48c9-8523-ce2dbbdc025c Revision: 0 Node Kind: directory Last Changed Rev: 0 Last Changed Date: 2011-07-21 19:01:07 +0700 (Thu, 21 Jul 2011)* But this command on Athol: *svn info http://localhost/svn/sample3 *gives this error result: *vn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory* *So the problem is in the client, not on the apache server. And both svnadmin and svn show the same problem.*
Re: Subversion: existing users
On 07/20/2011 12:14 PM, Nico Kadel-Garcia wrote: On Tue, Jul 19, 2011 at 10:30 PM, Andy Canfield andy.canfi...@pimco.mobi wrote: For example, I am on a Linux box named Lenny, logged in as 'andy'. I can ssh to hk.pimco.mobi as user 'andy', password 'psuedo'. But I don't want to. Instead, I would like to run the command: svn ... http://hk.pimco.mobi/svn/RepoName --username=andy --password=psuedo Whoa there nelly. You're mixing apples and oranges and kumquats. Go right over to the Red Book, and read the descriptions of *each* of HTTP, svnservee, and svn+ssh. Keep them distinct. Apparently I read the wrong Red Book. I read the one for the old version, not the nightly build Red Book. I shall download and install and read the Nightly Build Book. As far as I know 'svn' is the name of a client program, which can communicate with any server, and 'svn' is also the name of a protocol that the svn program uses to communicate with a server program named svnserve. My impression was that there were three possible servers, namely Apache, svnserve, and direct (file) access, and that which server was in use was controlled by the URL. The example command: *svn ... http://hk.pimco.mobi/svn/RepoName --username=andy* is a valid client command. The URL starts with http://; so it is expecting to talk to the Apache-based Subversion access channel, e.g. mod-dav*.so, located on hk.pimco.mobi. A similar command: *svn ... svn://hk.pimco.mobi/svn/RepoName --username=andy *is also a valid client command, where the URL starts with svn:// so it is expecting to talk to svnserve via port 3690 on hk.pimco.mobi. The above two commands can run on any computer with a connection to hk.pimco.mobi; i.e. any computer with an internet connection. Another valid command, which can only run on the server itself, would be *svn ... file:///var/svn/RepoName --username=andy* You said that I'm mixing apples and oranges and kumquats. Well, the svn client program is like my teeth, which can eat apples or oranges or kumquats (three kinds of servers depending on the URL). I usually only buy one kind of fruit at a time, and presumably we would only run one kind of server at a time. Since we want to have net access, I expect that we won't use direct (file://) access for anything except the svnadmin program, which as I recall can only be run on the server itself. So we are not yet decided on whether to use URLS that start with http:// (talking to the server known as apache mod_dav*.so) or URLS that start with svn:// (talking to the server known as svnserve). IMHO the 'svn' program is the client program which requests actions on a repository, and the Subversion server, either apache/mod_dav or svnserve, contains the code which actually manipluates the contents of the /var/svn repository directories. One quirk is that if he URL specifies direct access, e.t. svn ... file:///var/svn/RepoName, then where is the code which actually manipulates the contents of the /var/svn/RepoName directory? It must be hidden in svn itself, or perhaps svn forks a call to something like svnserve as a subtask to get the manipulations done for it, since there is no server program already running on the server computer. I read The Book already, but apparently the conversion from your ideas to those words to my eyes to my brain did not result in a replication of your ideas. I read the wrong version of The Book, the featured but obsolete version. I shall download the Nightly Build version ASAP. Thank you very much. But this does not match what you are telling me. Apparently my brain is pointed 89 degrees off from the direction your brain is pointed. Please point me in the right direction. See the explanations at http://svnbook.red-bean.com/. They go into much more depth than we can here. Thank you. The only well supported solution to this, so far, is to use SSH keys for a shared account, and to use those keys to use a forced command for that shared account, a command that enforces the user's name for that particular svnserve instance. I've previously tried, myself, to help set up a restricted shell for just such access, starting with the rssh tool, but didn't get very far. That would be a significant security improvement, and help protect the rest of the OS from unauthorized access with valid Subversion logins with Kerberized or other account access, rather than SSH keys.
Re: Subversion: existing users
Thank you very much. On 07/20/2011 05:44 PM, Stefan Sperling wrote: On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote: One quirk is that if he URL specifies direct access, e.t. svn ... file:///var/svn/RepoName, then where is the code which actually manipulates the contents of the /var/svn/RepoName directory? It must be hidden in svn itself, or perhaps svn forks a call to something like svnserve as a subtask to get the manipulations done for it, since there is no server program already running on the server computer. See this picture for a graphical representation of the various layers Subversion is composed of: http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture I study the diagram. Starting at the top: * commandline client app - since you don't put a name on it, apparently this is a program that I write. Same with GUI client apps - since there is no name it must be a program that I write. * Each of these access a Client Library. This Client LIbrary access the Working Copy Management Library. Somebody, presumably the WCML, access my working copy of the repository. * Then the Client Library access the Repository Access. This I have to assume is a PROTOCOL, not a PROGRAM. There are three; DAV, SVN, and Local. * At this point things DAV and SVN go through the Internet or any other TCP/IP network. * DAV goes through Apache and from here to mod_dav and through that to mod_dav_syn. The mod_dav_fs is not mentioned at all. * At this point we see the first blast. My copyof mod_dav_syn.so is timestamped about a year BEFORE the build date on Apache, which is within one day of the timestamp on mod_dav.sl. Whereas it is not unusual for a timestamp to be made later (e.g. via cp without -p), it is almost impossible for mod_dav_syn to have been build for this Apache and then the timestamp moved earlier. This must be why DAV access is crashing. * Alternatively, the SVN protocol will go to the svnserve program. * Below the mod_dav_syn layer and the svnserve layer and the repository local layer is the Subversion Repository. Significantly, this is diagrammed as data, not code. So mod_dav_syn must contain the code to manipulate the repository, and svnserve must also contain the code to manipulate the repository, and the Client Library (because of Local access) must contain the code to manipulate the repository. * Below the Subversion Repository component is either Berkeley DB or FSFS. I have already decided to use FSFS since I can look at it as it's sitting on the disk and therefore it is more conceptually transparent. * Significantly, the svn PROGRAM never appears on this diagram. Because the svn program is supposed to accept any of the three types of URL (http:// svn:// or file://) the svn program must be a commandline client app. I don't know how we got a year old version of mod_dav_syn but that is apparently what is screwing up the http:// protocol. Each layer has a public API that can be used by other layers. Clients like 'svn' and TortoiseSVN primarily use the client library's API. The client library in turn calls into what is referred to as the repository access (RA) library, which selects a repository access implementation depending on the protocol used (http://, svn://, file://). But there are exceptions where clients bypass the RA layer. E.g. if you run TortoiseSVN and select the 'Create repository here' command (the equivalent to 'svnadmin create'), TortoiseSVN calls directly into the libsvn_repos API (the API for the big box labelled Subversion Repository in the figure) to create a repository on local disk. Getting back to your original question, the so-called ra_local repository access module (labelled Local in the figure) which implements file:// access to the repository calls directly into the libsvn_repos API to manupilate a repository on local disk. The 'svn' client is linked to the repository access library, and hence, indirectly, to the ra_local library and to libsvn_repos, to support file:// URLs. So you could say that 'svn' contains a copy of the same code that svnserve uses to access the repository. The copy is not embedded into the 'svn' binary itself, but is loaded from a library file (libsvn_repos.dll on Windows) when 'svn' (or svnserve) is started. I read the wrong version of The Book, the featured but obsolete version. I shall download the Nightly Build version ASAP. Unfortunately google keeps showing links to the 1.1 version of the book. This problem has existed for ages. I was not confused by Google. I was confused by the web page http://svnbook.red-bean.com/. On that page there are two versions of the book. The first is labelled For Subversion 1.5, the other is labelled Nightly Build (for Subversion 1.7). I read the first one, under the traditional assumption
Re: Subversion access control
Thank you very much. On 07/20/2011 12:19 PM, Nico Kadel-Garcia wrote: On Tue, Jul 19, 2011 at 11:14 PM, Andy Canfield andy.canfi...@pimco.mobi wrote: One thing has hit my mind today that I don't think you realize ... I have never, in my entire life, seen a working Subversion system. Apparently Subversion, as distributed, doesn't work - the access authentications are deliberately turned off. I'm afraid it depends on your access requirements. Seriously. Which access technology are you using? svn+ssh (which I tend to recommend), or Apache (using https://), or svn directorly (svn://) Start with that and we'll walk you through it. OK, here goes. I would like to use http/https. I am not supposed to be working on the server, but on my notebook workstation. And svn or svn+ssh require port 3690 to be forwarded by the router, and we don't own the router. So I would prefer http and/or https. But on the actual server https is screwed up because mod_dev_svn.so is a year earlier than Apache, and apparently there is a version mismatch. When svn is enabled apache is dead. I have put in a request for my friend to re-install, but that could take a week. So for the interim I have installed mod_dav etc. on my notebook computer. FYI it is running Ubuntu Linux 1.04. This is for testing. Directory /etc/apache2/modes-enabled contains the file dav.load with this contents: *LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so* That same directoy also contains the file dav_syn.load with these contents: *# Depends: dav LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so* That same directory also contains the file dav_svn.conf which I altered; this is the altered contents: *# dav_svn.conf - Example Subversion/Apache configuration # # For details and further options see the Apache user manual and # the Subversion book. # # NOTE: for a setup with multiple vhosts, you will want to do this # configuration in /etc/apache2/sites-available/*, not here. # Location URL ... /Location # URL controls how the repository appears to the outside world. # In this example clients access the repository as http://hostname/svn/ # Note, a literal /svn should NOT exist in your document root. Location /svn # Uncomment this to enable the repository DAV svn # Set this to the path to your repository #SVNPath /var/lib/svn # Alternatively, use SVNParentPath if you have multiple repositories under # under a single directory (/var/lib/svn/repo1, /var/lib/svn/repo2, ...). # You need either SVNPath and SVNParentPath, but not both. #SVNParentPath /var/lib/svn SVNParentPath /data/svn # Access control is done at 3 levels: (1) Apache authentication, via # any of several methods. A Basic Auth section is commented out # below. (2) Apache Limit and LimitExcept, also commented out # below. (3) mod_authz_svn is a svn-specific authorization module # which offers fine-grained read/write access control for paths # within a repository. (The first two layers are coarse-grained; you # can only enable/disable access to an entire repository.) Note that # mod_authz_svn is noticeably slower than the other two layers, so if # you don't need the fine-grained control, don't configure it. # Basic Authentication is repository-wide. It is not secure unless # you are using https. See the 'htpasswd' command to create and # manage the password file - and the documentation for the # 'auth_basic' and 'authn_file' modules, which you will need for this # (enable them with 'a2enmod'). #AuthType Basic #AuthName Subversion Repository #AuthUserFile /etc/apache2/dav_svn.passwd AuthType Basic AuthName Lenny Subversion Repository AuthUserFile /etc/apache2/dav_svn.passwd # To enable authorization via mod_authz_svn #AuthzSVNAccessFile /etc/apache2/dav_svn.authz # The following three lines allow anonymous read, but make # committers authenticate themselves. It requires the 'authz_user' # module (enable it with 'a2enmod'). #LimitExcept GET PROPFIND OPTIONS REPORT #Require valid-user #/LimitExcept * * Require valid-user* * /Location * By the way, all three of the above files in /etc/apache2/mods-enabled are actually symbolic links to the same file name in ../mods-available. I used sudo htpasswd to create the /etc/apache2/dav_svn.passwd file: *andy:4izmp7W8TSqww* Also I created my subversion directory like this:\ *sudo bash mkdir /data/svn chmod a+w /data/svn* *ls /data/svn **drwxrwxrwx 2 root root 4096 2011-07-21 10:53 /data/svn* Now I point my browser to http://localhost/svn and I get a prompt for a user name and password. If I type in my valid user name andy and a completely spurious password, I get prompted again. But if I type in my valid user name and password (as given when I created the dav_svn.passwd file), the result is: *Forbidden You
Re: Subversion: existing users
Great... On 07/21/2011 10:01 AM, Andy Levy wrote: On Wed, Jul 20, 2011 at 22:42, Andy Canfieldandy.canfi...@pimco.mobi wrote: Thank you very much. On 07/20/2011 05:44 PM, Stefan Sperling wrote: On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote: One quirk is that if he URL specifies direct access, e.t. svn ... file:///var/svn/RepoName, then where is the code which actually manipulates the contents of the /var/svn/RepoName directory? It must be hidden in svn itself, or perhaps svn forks a call to something like svnserve as a subtask to get the manipulations done for it, since there is no server program already running on the server computer. See this picture for a graphical representation of the various layers Subversion is composed of: http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture I study the diagram. Starting at the top: commandline client app - since you don't put a name on it, apparently this is a program that I write. Same with GUI client apps - since there is no name it must be a program that I write. No. It's just a placeholder for any of the various clients that are available. Instead of listing all of the apps and having to maintain that list as they appear and disappear. I have 4 clients installed on my workstation - there wouldn't be any value in listing them all in that diagram, because any one of them could up and disappear tomorrow. Each of these access a Client Library. This Client LIbrary access the Working Copy Management Library. Somebody, presumably the WCML, access my working copy of the repository. As a user, you never see the client library. It's built into (or linked by) your client. But as a system administrator, for installing packages from Ubuntu, I often see library names etc. Also as a programmer I often run into libraries that no longer exist, library version problems, etc. But I know what you mean. As a user of subversion I should not see them assuming that my system administrator has taken care of things. Then the Client Library access the Repository Access. This I have to assume is a PROTOCOL, not a PROGRAM. There are three; DAV, SVN, and Local. The access layer is part of the program code. Again, as a user, you only care which ones you have available (to make sure you can access a repository using the method(s) provided by the administrator), not *how* they're implemented. At this point things DAV and SVN go through the Internet or any other TCP/IP network. DAV goes through Apache and from here to mod_dav and through that to mod_dav_syn. The mod_dav_fs is not mentioned at all. mod_dav is a standard Apache module which implements the WebDAV protocol. mod_dav_svn is an Apache module developed by/for the Subversion team which specifically implements Subversion using WebDAV (which is why it's in a box *inside* mod_dav's box). There is no mod_fs because ra_local doesn't utilize Apache as a server. But there is a file named mod_dav_fs.so on both the intended server and on my notebook trial server. If WebDAV is not specific to Subversion then maybe some other package / feature uses mod_dav_fs.so. Ahah! Google to the rescue. From http://httpd.apache.org/docs/2.0/mod/mod_dav_fs.html I learn that mod_dav_fs.so acts as a support module for mod_dav and provides access to resources located in the server's file system. At this point we see the first blast. My copyof mod_dav_syn.so is timestamped about a year BEFORE the build date on Apache, which is within one day of the timestamp on mod_dav.sl. Whereas it is not unusual for a timestamp to be made later (e.g. via cp without -p), it is almost impossible for mod_dav_syn to have been build for this Apache and then the timestamp moved earlier. This must be why DAV access is crashing. It's not 100% definite, but it's an extremely likely root cause. Alternatively, the SVN protocol will go to the svnserve program. Below the mod_dav_syn layer and the svnserve layer and the repository local layer is the Subversion Repository. Significantly, this is diagrammed as data, not code. So mod_dav_syn must contain the code to manipulate the repository, and svnserve must also contain the code to manipulate the repository, and the Client Library (because of Local access) must contain the code to manipulate the repository. Below the Subversion Repository component is either Berkeley DB or FSFS. I have already decided to use FSFS since I can look at it as it's sitting on the disk and therefore it is more conceptually transparent. FSFS doesn't expose the files directly. It's still a database of sorts, just not a BDB database. You still need a Subversion client to access the files. But I don't need a Subversion client to see the files, to read the files, and therefore to learn how things are stored. I'm the kind of guy who has looked at the directory file structure created by MySQL for it's databases. It becomes possible to see the low-level implementation in case
Re: Subversion access control
OFF THE SUBJECT OF APACHE, NOW TRYING TO ACCESS SVNSERVE VIA PORT 3690 /var/svn/config/svnserve.conf has been changed from the default to show *anon-access = none password-db = passwd authz-db = authz* The passwd file contains *andy = canfield* The authz file contains: *[/sample] andy = rw* The repository /var/svn/sample contains a subdirectory 'conf' containing svnserve.conf, passwd, and authz files which are symbolic links to the files in /var/svn/config. The svnserve was run with this command: */usr/bin/svnserve --daemon --root=/var/svn --config-file=/var/svn/config/svnserve.conf * I have one repository defined named sample. The command: *svn info svn://localhost/sample *Gave this response: *Authentication realm: svn://localhost:3690 5a3a5c16-49ac-46d9-b1e8-d48cc97c4754 Password for 'andy': Authentication realm: svn://localhost:3690 5a3a5c16-49ac-46d9-b1e8-d48cc97c4754 Username: andy Password for 'andy': --- ATTENTION! Your password for authentication realm: svn://localhost:3690 5a3a5c16-49ac-46d9-b1e8-d48cc97c4754 can only be stored to disk unencrypted! You are advised to configure your system so that Subversion can store passwords encrypted, if possible. See the documentation for details. You can avoid future appearances of this warning by setting the value of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/Users/andy/.subversion/servers'. --- Store password unencrypted (yes/no)? yes svn: Authorization failed * [1] Why does it ask for the password for andy, then ask for a user name and password? [2] What is an authentication realm? [3] Why does it talk about STORING my password, when as far as I know all subversion does is check your password against the contents of the passwd file. [4] Why doesauthentication fail? [5] Why does authentication fail immediately afer the first time? [6] I now have an entire directory tree named .subversion in my home directory. I have no idea what any of this stuff is or is supposed to be. Is this what is blocking me from my repository? [7] The repository was created by svnadmin create ... which has to be executed as root. Does this mean that only root can access this repository from now on? That doesn't make sense.
Re: Subversion: via Apache
On 07/18/2011 09:34 AM, Geoff Hoffman wrote: Test your config with -t Option -t on what command line? -t for svnserve means tunnel; svnadmin and svn have no -t option.
Re: Subversion: list of respositories
On 07/18/2011 09:35 AM, Andy Levy wrote: Please Reply to All to keep discussion on the list. List convention is to bottom-post and quote inline. Please do not top-post. On Sun, Jul 17, 2011 at 22:29, Andy Canfieldandy.canfi...@pimco.mobi wrote: If I set up http://example.com/svn to be a way to use apache to communicate with the svn service on the example.com server then is pointing my browser to http://example.com/svn; supposed to give me some kind of web page? Because I do not remember seeing anything about that in the book. You're looking for SVNParentPath. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html My locate /svn entry in httpd.conf contains an SVNParentPath line. I thought I sent that to you. Here (again) is the diff: *... diff httpd.conf.good httpd.conf.subversion 127c127 #LoadModule dav_module libexec/apache2/mod_dav.so --- LoadModule dav_module libexec/apache2/mod_dav.so 154c154 #LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so --- LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so 1501a1502,1515 # This spells out where the subversion repositories go Location /svn DAV svn # any /svn/foo URL will map to a repository /var/svn/foo SVNParentPath /var/svn # how to authenticate a user AuthType Digest AuthName Subversion repository AuthDigestDomain /svn/ AuthUserFile /etc/svn-auth-file # only authenticated users may access the repository Require valid-user /Location * On 07/17/2011 07:07 PM, Andy Levy wrote: On Sun, Jul 17, 2011 at 02:06, Andy Canfieldandy.canfi...@pimco.mobi wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: sshusern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. There is, but only if you serve via Apache.
Re: Subversion: list of respositories
On 07/18/2011 09:36 AM, Nico Kadel-Garcia wrote: On Sun, Jul 17, 2011 at 8:07 AM, Andy Levyandy.l...@gmail.com wrote: On Sun, Jul 17, 2011 at 02:06, Andy Canfieldandy.canfi...@pimco.mobi wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: ssh usern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. There is, but only if you serve via Apache. Even then, it won't find repositories that are not built into the Apache layout or the elevant parent directory. I would think that it looks at SVNParentPath and tries to treat every subdirectory of that as a repository.
Re: Subversion: via Apache
I have requested our system administrator re-install Apache and all it's mod_dav modules and tell me the distribution versions of everything. After it gets done I can re-test. In the meantime I can hope to get svn talking to svnserve via port 3690. So far failed on permissions, but more testing tomorrow.
Subversion access control
We are running svnserve on a Mac OS X. I can not get the subversion server to control access. I executed the server by this command: */usr/bin/svnserve --daemon --root=/var/svn --config-file=/var/svn/config/svnserve.conf* As long as file /var/svn/config/svnserve.conf contains the original line: *# anon-access = read* this command works: *svn info svn://localhost/sample* Of COURSE I don't want random hackers to have read access to my source code ! As soon as that line is changed to *anon-access = none* the error message comes back: *svn: No access allowed to this repository* (By the way, I originally changed the # to a space and got an error on that line. Apparently the keyword MUST start in the first column.) I have added this line to 'passwd' - *andy = canfield* I have added these lines to 'authz' - *[/sample] andy = rw* The documentation for 'svn' says that if you don't give a user name and password you will be prompted for them. I have never under an circumstances been prompted. Even this command fails with the same error message: *svn info --username=andy --password=canfield svn://localhost/sample*
Subversion: list of respositories
How do you get a list of repositories from svnserver? The only way I can figure out is: *ssh usern...@example.com sudo bash ls -ld /var/svn/** And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way.
Subversion: via Apache
WHOA! Near as I can tell, if you have an apache2 server offering web sites http://example.com/alpha http://example.com/beta http://example.com/gamma and you configure the apache2 web server for Subversion support, suddenly you can no longer access alpha and beta and gamma. DOES SUBVERSION TAKE OVER THE ENTIRE APACHE SERVER? Apparently so. Yet the book makes no mention of this! Well, we can not have subversion stealing our apache server; after all we plan to use subversion to maintain a web site being hosted by that very server. So we'll have to use svnserve.
Subversion: Access control management
The file /var/svn/sample/README.txt says *This is a Subversion repository; use the 'svnadmin' tool to examine it. Do not add, delete, or modify files here unless you know how to avoid corrupting the repository.* but as far as I know there are no svnadmin tools to control access to the repository; the only way to control access to the repository is to manually edit the files in the 'conf' subdirectory, which the README.txt file tells you not to do.
Subversion: existing users
The most obvious authorization scheme is that of the host server; if there is a user named andy on that server with a password jackel then I would like to simply be able to talk to the subversion server as user named andy password jackel. This is how ssh and sftp work. But apparently subversion can't handle that. True?
Re: Subversion: via Apache
I removed the Location /svn block. No, Apache does not function. *telnet hk.pimco.mobi 80 Trying 202.181.201.137... Connected to hk.pimco.mobi. Escape character is '^]'. HEAD / HTTP/1.0* (pressed Enter twice) *Connection closed by foreign host.* In my last message I did not include the Apache version number; the output of '/usr/sbin/httpd -v' is: *Server version: Apache/2.2.14 (Unix) Server built: Feb 10 2010 22:22:39* Is there any way to check the version number of the SVN modules if they are not working? On 07/17/2011 08:15 PM, Andy Levy wrote: Strip your httpd.conf.subversion down to ONLY load the modules. Do not include theLocation /svn block. Does Apache function? Telnet to hk.pimco.mobi on port 80 and enter the following: HEAD / HTTP/1.0 Then ENTER twice. You should get an HTTP/1.1 200 OK response (see http://tonycode.com/wiki/index.php?title=Making_HTTP_requests_via_telnet for more details on this). If this doesn't work, then you likely have a difference between the version of Apache you're running and the SVN modules. They need to be built using the same version of APR, IIRC.
