On 7/22/2011 1:45 AM, Andy Canfield wrote:
>
>> 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.
The usual sysadmin rule is that if the documentation and code differ,
they are both wrong.
> 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.
No, you either run svanamin as root and change ownership/permissions
later, or su to the owning user which sometimes involves options to su
to run an appropriate shell if the user in question doesn't have one for
direct logins.
> 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.
Websvn, viewvc, etc., generally only need read access.
> 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.
I think you've typed a lot more already without accomplishing this than
it would have taken to create the separate passwd file with three users
that either svnserve or apache need for their simple form of authentication.
> 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.
There are a couple of catches. One is that the system passwords in
/etc/shadow are only readable by root - intentionally to prevent
password-cracking programs from easily breaking the encryption. Giving
other programs access opens an assortment of potential vulnerabilities.
Another is that it only solves the problem when you only have one
machine and you want all involved parties to have access to everything.
This is rarely the case as you start adding network services.
> I look at setting up Subversion authentication, and the first option I
> hope for is:
> use-what-you-already-have = yes
If what you already have is LDAP, you probably can. There are ways to
make apache work with the system passwd/shadow files but I'm not sure
what the best approach currently is. Mod_auth_pam used to work but I
don't think distributions include it now and you have to give apache
read access to /etc/shadow to use it with the system files.
> 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.
Large groups will likely already have some network authentication
mechanism set up (and really large groups will have a different set of
people managing it...). Apache has a large set of authentication
mechanisms/modules so you can probably make it work with whatever you
need. However, even large groups often use outside contractors for
development work and there may be times when you want to control access
separately for subversion or certain other services.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-07-22 18:15:15 CEST