1 This is the duct tape that ties repo.or.cz together. You will find
2 some hardcoded paths inside, and some other kludgy stuff.
4 The user interface is kept in the cgi/ subdirectory (repo.or.cz/m/ is symlink
7 There are two modes of operation for each project: hosting and mirroring.
13 (All uids and gids are allocated from range 65536..infty. All passwords are
14 stored in DES crypt(3) format because Apache is moronic.)
16 (This is vaporware: No such thing exists yet. But workin' on it.)
19 This is how the push access is provided:
21 The whole setup is confined in a chroot with its own instance of sshd running.
22 The chroot looks like:
29 /bin/git-unpack-objects
30 /bin/git-update-server-info
40 There is a (non-chroot) system user 'repo' and a group of the same name (the
41 webserver is member of the group; TODO: suexec). The files in /etc are owned
42 by repo.repo and group-writable, as well as all files in /srv/git/*/ but
43 refs/** and objects/** which are repo.projname.
46 When you register a project, it will get a gid allocation and you will set a
47 password for it. The triple is stored in a group(5) file (but containing just
50 projname:crypt:gid:list,of,users
52 When you register a user, it will get a uid allocation and you will upload
53 an ssh public key for it. The user is stored in a passwd(5) file (but
54 containing just the repo.or.cz users; 65534 is nogroup):
56 username::uid:65534:realname:/dev/null:/bin/git-shell
58 The authorized keys are stored in /etc/sshkeys/username.
60 When you (un)assign user to a project, you just manipulate the list of users
61 for the project in /etc/group. The web interface for the project administration
62 is protected by the group password; chroot/etc/group is used as the htpasswd
69 To keep things safe and neat, repo.or.cz is job-controlled: the only thing the
70 cgi script does is scheduling a clone job (by creating a directory with some
71 files at a magic location) and then the clonecheck.sh script is invoked every
72 minute by cron (under more reasonable uid) to check if there are any jobs
73 scheduled, and calls clone.sh to do the clone itself, notifying the user about
76 The script that keeps repositories up-to-date is updatecheck.sh, being run
77 by cron every hour and calling update.sh for all the relevant repositories.
79 updateglibc.sh stands somewhat out of the crowd and keeps the Git mirror of
80 the glibc CVS repository up-to-date, so it's probably not interesting for