On 07/21/2011 09:33 PM, Nico Kadel-Garcia wrote:
On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield<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.
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 version of
'/etc/passwd' to me, and a usually unnecessary redundancy.
I look at setting up Subversion authentication, and the first option I
hope for is:
use-what-you-already-have = yes
Of course, my experience is in small groups, not big ones. For example,
it has been decades since I've worked with a project involving more than
one programmer. That's why I have to LEARN Subversion; because I've
never needed it before and I"m not even sure that I need it now. But it
sounds like a useful skill.
Thanks for all.
