Continued: this message covers the last part.
| Repository Administration[[Repository Administration]]
| ------------------------------------------------------
|
| A repository administrator uses the following tools to set up
| and maintain access to the repository by developers.
|
| * linkgit:git-daemon[1] to allow anonymous download from
| repository.
|
| * linkgit:git-shell[1] can be used as a 'restricted login shell'
| for shared central repository users.
|
| link:howto/update-hook-example.html[update hook howto] has a good
| example of managing a shared central repository.
This part is fairly stale. We only talk about allowing anonymous
fetching via git-daemon and pushing via git-over-ssh. The readers
would want to be aware that they can set up their hosts for fetching
and pushing via git-over-http aka "Smart http", and browsing via
gitweb. We should definitely at least mention these, and we may
even want to describe them at the same level of detail as the
existing examples.
I wonder if we also want to mention (but not describe, just make the
readers aware of) widely deployed hosting/browsing solutions such as
gitolite, gerrit code review, and cgit.
Do tasks that are described here have impact on the use of these
third-party tools? For example, I understand gitolite does not
require one UNIX user per biological human user, but the vanilla
push-over-ssh described in these examples does. I guess the burden
of telling the users to "unlearn everything you read about setting
up the vanilla git-over-ssh when you use gitolite" falls on gitolite
doc, so in that sense we shouldn't have to worry about doing any of
that here.
| Examples
| ~~~~~~~~
| We assume the following in /etc/services::
| +
| ------------
| $ grep 9418 /etc/services
| git 9418/tcp # Git Version Control System
| ------------
OK.
| Run git-daemon to serve /pub/scm from inetd.::
| +
| ------------
| $ grep git /etc/inetd.conf
| git stream tcp nowait nobody \
| /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
| ------------
| +
| The actual configuration line should be on one line.
OK.
| Run git-daemon to serve /pub/scm from xinetd.::
| +
| ------------
| $ cat /etc/xinetd.d/git-daemon
| # default: off
| # description: The Git server offers access to Git repositories
| service git
| {
| disable = no
| type = UNLISTED
| port = 9418
| socket_type = stream
| wait = no
| user = nobody
| server = /usr/bin/git-daemon
| server_args = --inetd --export-all --base-path=/pub/scm
| log_on_failure += USERID
| }
| ------------
| +
| Check your xinetd(8) documentation and setup, this is from a Fedora system.
| Others might be different.
OK, but which vintage of Fedora? ;-)
| Give push/pull only access to developers.::
This entry may mislead the readers if the "access" this section
talks about is to the git-daemon we just set up in the above. We
should clarify that this is about git-over-ssh access, i.e. the
users will be doing this:
$ git push/pull host.xz:/pub/scm/project
or
$ git push/pull ssh://host.xz/pub/scm/project
or somesuch.
| +
| ------------
| $ grep git /etc/passwd <1>
| alice:x:1000:1000::/home/alice:/usr/bin/git-shell
| bob:x:1001:1001::/home/bob:/usr/bin/git-shell
| cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
| david:x:1003:1003::/home/david:/usr/bin/git-shell
| $ grep git /etc/shells <2>
| /usr/bin/git-shell
| ------------
| +
| <1> log-in shell is set to /usr/bin/git-shell, which does not
| allow anything but `git push` and `git pull`. The users should
| get an ssh access to the machine.
| <2> in many distributions /etc/shells needs to list what is used
| as the login shell.
One possible mis-interpretation of <1> is "Thanks to these git-shell
entries, the users will get `push/pull` accesses to the box; they
separately need ssh access to the box (to do something more than
that, if desired)".
In reality, this configuration _requires_ them to have an ssh access
to the box and these entries restricts them to only run push/pull
against the host. We may want to rephrase to clarify.
| CVS-style shared repository.::
| +
| ------------
| $ grep git /etc/group <1>
| git:x:9418:alice,bob,cindy,david
| $ cd /home/devo.git
| $ ls -l <2>
| lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
| -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
| -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
| -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
| drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
| drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
| drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
| $ ls -l hooks/update <3>
| -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
| $ cat info/allowed-users <4>
| refs/heads/master alice\|cindy
| refs/heads/doc-update bob
| refs/tags/v[0-9]* david
| ------------
| +
| <1> place the developers into the same git group.
| <2> and make the shared repository writable by the group.
| <3> use update-hook example by Carl from Documentation/howto/
| for branch policy control.
| <4> alice and cindy can push into master, only bob can push into doc-update.
| david is the release manager and is the only person who can
| create and push version tags.
OK.
| HTTP server to support dumb protocol transfer.::
| +
| ------------
| dev$ git update-server-info <1>
| dev$ ftp user@xxxxxxxxxxxxxxx <2>
| ftp> cp -r .git /home/user/myproject.git
| ------------
| +
| <1> make sure your info/refs and objects/info/packs are up-to-date
| <2> upload to public HTTP server hosted by your ISP.
This may want to be removed, for two reasons. Nobody should be
using dumb HTTP anymore, and the "cp" implies that the repository is
not maintained at the isp.example.com site but is synchronized
manually from some other location with _only_ ftp access into it,
which is not a typical way to run your project (I admit I did this
myself in very early days of Git when Linus was still running the
project).
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html