On 07/21/2011 09:33 PM, Nico Kadel-Garcia wrote:
> On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield<andy.canfield_at_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.
Received on 2011-07-22 08:46:56 CEST