> -----Original Message-----
> From: Mark Phippard [mailto:MarkP@softlanding.com]
> Sent: Friday, June 04, 2004 9:02 PM
>
> I do not really understand how serving up your repository
> would involve office politics?
I don't either. Please leave it as that or else, this thread will turn into
me bickering about my office politics.
> It sounds like you have control over this server and you
> have clearly already setup some sort of web server on this
> server. Why can't Apache just serve the repository?
I do have control over the scm server and that's it. I don't have access to
anything else so I can't use the company ldap server to authenticate the
users. I don't also have authority over the users so I can't really
"instruct" them to do anything.
Although, Karl have pointed out to me that I don't need to create local user
account with apache but I can't get it to work. More on this when I have
more time to try figure this out.
> Generally, using HTTP and SSL would be an easier sell in
> most organizations.
Not around here. I can't get ssh installed on any of the serve except the
one I have control over.
> Normally, the resistance to using
> Apache is setting it up on the server in the first place.
> Once you are using Apache you can use whatever user and
> password system you want.
I find that Apache is not difficult to setup because the Gentoo distribution
I use does most of the work for me. Setting up Apache for Subversion is
another story.
Also, so far I have only seen two types of authentication system used with
Apache. That is the basic username password scheme and also ssl certs.
Please define "whatever user and password system". I am more then willing to
explore other options if it fits into the limitation I am facing and not
very involved for administration work beyond the initial setup.
> >> They enter that hash rather than their plaintext password
> the one time
> >> that svn asks them for it, and voila, everything works.
> >>
> >> As an added benefit, they can use whatever hash function they want!
> >
> > NO! :) It's hard enough to get people to use better
> password, getting
> them
> > to enter a hash password is going to be hell.
>
> I do not understand this one either. Your users do not want
> to give you plain text passwords, and you have said you do
> not want to receive them, why can't your users be instructed
> to make a hash of their password and give you the hash? That
> seems to solve the problem and is relatively easy to do.
> Users that do not care can use plain text passwords.
Giving instruction to the users to give me any passwords (hashed or
otherwise) means that I will have to go collect them. That's the way it work
around here. I'm sure no one will be willing go around to collect password
for 100+ user or so. In the long run that will be an administrator's
nightmare.
> In your own proposal, this is step 1:
>
> > 1. The server store standard hashed password in the
> password file (Yes,
> I
> > know it is crackable but I am not too concern about
> security. If I am, I
> > will be using the other method to access the server).
>
> So how does your server get the hashed passwords to store if
> you are not willing to do that? If you are willing, then
> why do you need to do anything else?
Some form of web interface for user to change their password along with
initial password for them to login to change their password. Hashing will be
done in the cgi script. My aim is to be as maintenance free as possible
because I am not an administrator and my performance is not evaluated based
on doing system administration work. But I am willing to spend some time
initially to set it up so that it is "maintenance free (tm)".
> Just trying to understand ...
Believe me when I say I am also trying to understand.
Regards,
Han.
----
Ng, Wey-Han
Atos Origin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 13:32:20 2004