Thus said David Mason on Sat, 14 Dec 2013 16:33:57 -0500:
> cp master.fossil $s.fossil
If you create a ``master.fossil'' that is then copied, each project will
have the exact same project-id, and will not be unique. This may not be
what you want. I would move the creation of each fossil inside the loop:
jot -w 'student%d' 3 | while read s
do
fossil new -A teacher $s.fossil
# SETUP tauser account in $s.fossil
# SETUP $s account in $s.fossil
# SETUP remote_user_ok
# SETUP SSH public key that they have sent you
done
One problem that you'll need to figure out how to deal with... the
``fossil user new'' command prompts for a password. In this case,
you don't even really need a password because SSH is being used
for authentication to both the server and the repository (using
REMOTE_USER). So perhaps instead of using the fossil for creating the
users, you could just use sqlite3 (or fossil sqlite):
sqlite3 $s.fossil "INSERT INTO user (login,cap) VALUES ('$s','v');"
You don't want to set the default user when you create the $s.fossil to
be the student---it should probably be the teacher account.
> Then tell them to do:
> fossil clone ssh://fossil@server/ course.fossil
> fossil user -R course.fossil default student1
You'll need to have the student create student1 in this repository
before it can be set as a default:
fossil user -R course.fossil new student1
When you clone, user accounts are not cloned (unless you have the
requisite privileges and an unprivileged student account will not have
that).
> Well, except a student could spoof a grade change as coming from me or
> the TA and I wouldn't know about it unless I fired up the UI for that
> student's repo.
I suppose it depends on how the grade changes are handled. If the Wiki
is used for tracking grades, and the student user does not have the
rights to edit the Wiki then it will not be possible.
This means you'll have to tweak the default capabilities in the loop
where you create the fossils and then be more explicit in the
capabilities that the student account receives (and perhaps the tauser).
In fact, you might want to review all the capabilities and disable those
that aren't required for what you're doing (do it in the loop).
> 1) there's no way to (dis)allow check-in permissions for some
> directory trees
Correct.
> 2) what is to prevent the student from doing things as admin on their
> copy of the repo and then committing that back to the server?
If you use the http mode for fossil, the permissions assigned to the
user account are enforced. So if the student1 account is only setup as a
user that has no Wiki editing, for example, he won't be able to push any
Wiki changes to the server. Sure, he can fire up the UI in his local
clone and edit the Wiki there, but anything he commits will never be
accepted by the source.
Andy
--
TAI64 timestamp: 4000000052ace771
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
