Den 29. jul 2005 kl. 18:12 skrev David Anderson:
> Jon Bendtsen wrote:
>> I've always wondered why SVNSERVE does not support PAM. CVS does, and
>> isnt subversion supposed to be an replacement for CVS?
> CVS supports it? That's news to me. You mean some weird hack added on
> top of CVS supports it?
Well, my cvs pserver in debian supports pam.
> Looking throught the archives of the cvs list, there is an unofficial
> patch in the CVS issue tracker to hack PAM support into CVS. It
> seem to be in the mainline, even after 4 years or so of waiting in the
> issue tracker.
That may be true
>> My users complain that using svn+SSH takes twice the time than a user
>> added to the password file in the conf directory.
> I am in total comprehension failure here. What does PAM have to do
> the passdb in the repository configuration? Surely, adding PAM
> authentication support to svnserve would let you authenticate against
> system facilities, and would be at least as unwieldy to set up as a
> shell account for svn+ssh, if not more because of the PAM
> reconfiguration required.
I have an existing setup where every user has a ssh account. They can
ssh in using their windows username because of pam_winbind.
However, when using svn+ssh, checkout takes twice as long as if i
add them to the password database that SVNSERVE does support.
However, after getting http to use pam, then it takes about the same as
SVNSERVE. Measured by a stopwatch, noting scientific.
So, i guess that encryption/decryption is the bottleneck? Maybe, but the
server is a 3GHz P4, and so are the clients. So i didnt expect that much
of a drop in speed.
>> i guess i can use apache2, i just figured that it is strange that
>> SVNSERVE does not support PAM, which is pretty much the standard unix
> It is the standard-ish linux auth, I'll grant you that. But standard
> Unix auth? That's perhaps going a little far. What about the BSDs?
I remember having read about solaris and pam, so i figured that everyone
could use them. I can not possible imagien that *BSD does not use pam.
> Anyhow, extended authentication support in svnserve is on the todo. It
> isn't done yet because there were more important things to do (the new
> repository backend, locking, performance enhancements) and that nobody
> picked up the task. If you put aside the few Svn devs who work on
> Subversion for a living, this is your standard open source project:
> if you require something that nobody else cares about in the
> immediate future, you either step in and do it, pay someone to step
> in and do it, or be patient until someone steps in and does it.
I know i know, and it is not that importent since we do have
mod_auth_pam for apache.
I just wondered, thats it.
> My current todo list is quite full at the moment with
> authentication and authorization enhancements to svnserve, notable
> SASL integration. If the SASL library we choose when I get there
> natively allows using PAM as an authentication backend, then you're
> in luck. Otherwise, we don't have much choice but wait until
> someone comes along and picks up this todo.
> The other option, as I said above, if you really really need PAM
> right now this instant, would be to pick up a contract with
> CollabNet (not sure they do feature-request contracts, but it can't
> hurt to ask) or a freelance developer knowledgeable with Subversion
> and have the feature implemented by paid employees.
I got it to work using apache2. But it did take some time. Maybe the
directly mention that mod_auth_pam exists.
Sure there are still some things i'd like better, like being able to
use groups as well, but i can
get that semi working by using scripts to read the groups and stuff
the members into the
It's harder to stuff users and encrypted passwords into a file. But
groups are easy.
However, that SASL you talk about does sound interresting, i hope it
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jul 29 18:34:09 2005