I'm using subversion though svnserve. The subversion repository is on
a system where users do not have accounts. So all the repository files
are owned by the "svn" system user, and the "svnserve" daemon (running
as user "svn") performs user-authentication as usually.
The problem is that the svn protocol does not provide a way for the
users to set their passwords. So they have to tell me (the
administrator) their passwords, and I have to edit the respective
pain-text files. For several reasons I do not want to have users
telling me their passwords. One can think of several such reasons:
Users are trained not to reveal passwords, and you don't want to go
against that, a user might give you a sensitive password which you'd
rather not know, and so on.
Luckily since the svn client caches passwords it would not be very
inconvenient (for the users) to assign random passwords to them. So
here's a simple technique I've devised to do just that. It's not
rocket-science---just a couple of simple scripts---but they work for
me, and I thought they could work for others too:
Inside "$REPOS/conf" setup "svnserve.conf" to read user-passwords from
the file "$REPOS/conf/passwd". This file will be automatically
generated, so you don't have to edit it manually. Actually event if
passwd gets deleted it can be recrated from the information in the
master users' list. Inside "$REPOS/conf", create a file named "users"
which will be your master users' list mentioned above. Initially it
contains lines like this (which you entered manually, to corespond to
your valid users):
The first word is the user-name, then a space, and then a valid
email-address for the user. After you edit this file you run the
"users_update.sh" script, which is conviniently also located inside
"$REPS/conf". The users_update script does the following:
- scans the users list.
- if it sees that a line has two fields (as all the lines in the
example above do) it generates a random password, and edits the
line adding this random-password as a third field. It then sends
an email to the user informing her of the new password (using a
message template also stored in "$REPOS/conf", and called
- if instead it sees that a line has three fields, it does nothing
- finaly it generares the "$REPOS/conf/passwd" file from the "users"
- as a finishing touch, it makes sure than both the master users
list, and the passwd files are readable only by the "svn" user
After running "update_users.sh", the edited users list would look like
npat email@example.com bc45ed12
joe firstname.lastname@example.org aacc1234
foo email@example.com 1276fe27
and the generated passwd file:
# *** DO NOT EDIT ***
# Automatically generated.
# Generated: Sun Aug 1 10:08:18 EEST 2004
# Edit the "users" file instead,
# and run "users_update.sh" to regenerate
npat = bc45ed12
joe = aacc1234
foo = 1276fe27
The "$REPOS/conf/" directory looks like this:
passwd ; the auto-generated passwords file
svnserve.conf ; server config file
users ; master users list
users_emain_msg.txt ; email template
users_update.sh ; update script
The users have also received mail informing them of their passwords.
If you want to add new users, simply edit the "users" file (adding
more lines to it), and rerun "update_users.sh". If you want to change
the password of a user (for whatever reason), edit the "users" file,
removing the third field from the respective line, and rerun
If you are interested you can find the respective files and scripts
They 're not much, but they might come handy.
P.S. I have also written a simple post-commit script that uses the
master users list (conf/users) as an address-book in order to
adjust the "From:" headers when it sends commit-updates to
watchers. If you are interest, drop me a line and I will clean-it
up and put it online too.
He who joyfully marches to music in rank and file has already earned
my contempt. He has been given a large brain by mistake, since for
him the spinal cord would fully suffice.
-- Albert Einstein
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Aug 1 22:36:58 2004