Thus said David Mason on Sat, 14 Dec 2013 10:38:46 -0500:
> That's great! I had obviously misunderstood. I thought that the client
> side had different interactions because it used to interact with the
> shell, and now didn't.
I actually made it so the new Fossil server code emulates the old client
shell probing interaction so that the client thinks it is talking to a
shell. This allowed for backwards compatibility.
Right now, the user that Fossil uses to synchronize commits is the user
found in the URL e.g., for a URL of ssh://fossil@server//proj.fossil,
the client will use ``fossil'' as the user that it synchronizes with.
This means that you have to override the user using REMOTE_USER and an
SSH key on the server. You can automate this on a newly created Fossil
with sqlite3:
$ sqlite3 user1proj.fossil "INSERT INTO config VALUES
('remote_user_ok',1,strftime('%s','now'));"
Then in the ~fossil/.ssh/authorized_keys:
command="REMOTE_USER=user1 ./bin/fossil-trunk http ./user1proj.fossil" ssh-dss
...
Using http in the command means that the user1 user will only be able to
do what user1 is allowed to do with the repository (if you want them to
have full access, then just use test-http). And then they can clone by
simply doing:
fossil clone ssh://fossil@server/ proj.fossil
And each student will get access to the fossil their SSH key dictates.
> 3) I don't understand the admin-user fully particularly server vs.
> client. If I am the admin on the server, is there a reason why the
> students need the -A on the clone command? Do they need to be admin,
> if all they are doing is committing code?
The admin user really only matters when the clone is being used in
server mode. Obviously if you have file level access to the clone, you
can manipulate it even if you are not an admin user in Fossil. So from
the client side, it isn't really necessary. But, the client side of
Fossil needs to know which user to use when making commits. This is
typically the URL user, but in this case, I would think ``fossil'' is
not an optimal username for all commits.
Using -A to set the admin user was really a shortcut . You can certainly
clone with just the fossil user as the admin, then instruct them to add
a new user and make that user the default. It won't even really matter
if that user is a developer because that really only matters when in
server mode.
fossil clone ssh://fossil@server/ proj.fossil
fossil user -R proj.fossil new user1
fossil user -R proj.fossil default user1
But, if you don't mind seeing a student's commits showing up as
``fossil'' then this may not be necessary. In fact, with Fossil 1.27,
the URL user is *not* the default admin user as it is in trunk, so if
they start with 1.27, then the admin/default user will be set to
whatever username their OS is reporting.
> 4) could I not add code on the server side to use the user from the
> ssh forced command to tag the commits, or are they just copied over
> unchanged from the client and changing it would somehow break
> something?
No, this is not possible because the username is part of the commit and
written in the artifact manifest, so it is just copied with the
artifact. It is possible to change the user after it has been committed,
but that only adds a new artifact that overrides the original, it
doesn't alter it. There is no code to do this automatically that I am
aware of so you would have to script it. Probably not worth it.
> Where is the recvfrom data available? only on the server?
Each server maintains its own version. To see it, login to the UI as an
admin and then click on any commit. You'll see a line that looks like:
Received From: user1 @ 172.31.21.11 on 2013-12-14 19:26:57
> On the server could I refuse commits if the tag on the commit differed
> from the ssh force tag?
I don't think this is currently possible, and again, I don't think this
is worth it.
Probably better just to provide clear instructions on how to set the
username.
Let me know if this helps clarify your approach.
Thanks for using Fossil. :-)
Andy
--
TAI64 timestamp: 4000000052acb4db
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
