README

   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.
   3
   4 The user interface is kept in the cgi/ subdirectory (repo.or.cz/m/ is symlink
   5 to that).
   6
   7 There are two modes of operation for each project: hosting and mirroring.
   8
   9
  10 Hosting mode
  11 ------------
  12
  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.)
  15
  16 (This is vaporware: No such thing exists yet. But workin' on it.)
  17
  18
  19 This is how the push access is provided:
  20
  21 The whole setup is confined in a chroot with its own instance of sshd running.
  22 The chroot looks like:
  23
  24         /bin/sh
  25         /bin/git-shell
  26         /bin/git-upload-pack
  27         /bin/git-receive-pack
  28         /bin/git-rev-list
  29         /bin/git-pack-objects
  30         /bin/git-unpack-objects
  31         /bin/git-update-server-info
  32         /bin/git-repack
  33         /sbin/sshd
  34         /dev/randomstuff
  35         /lib/randomstuff
  36         /var/empty
  37         /var/run/mob
  38         /srv/git/...
  39         /etc/group
  40         /etc/passwd
  41         /etc/sshkeys/*
  42         /etc/ssh/randomstuff
  43
  44 There is a (non-chroot) system user 'repo' and a group of the same name (the
  45 webserver is member of the group; TODO: suexec). The files in /etc are owned
  46 by repo.repo and group-writable, as well as all files in /srv/git/*/ but
  47 refs/**, info/**, and objects/** which are repo.project. /var/run/mob has zero
  48 permissions bits but is owned by the mob user.
  49
  50
  51 When you register a project, it will get a gid allocation and you will set a
  52 password for it. The triple is stored in a group(5) file (but containing just
  53 the project groups):
  54
  55         projname:crypt:gid:list,of,users
  56
  57 When you register a user, it will get a uid allocation and you will upload
  58 an ssh public key for it. The user is stored in a passwd(5) file (but
  59 containing just the repo.or.cz users; 65534 is nogroup):
  60
  61         username:x:uid:65534:email:/:/bin/git-shell
  62
  63 The authorized keys are stored in /etc/sshkeys/username.
  64
  65 When you (un)assign user to a project, you just manipulate the list of users
  66 for the project in /etc/group. The web interface for the project administration
  67 is protected by the group password; chroot/etc/group is used as the htpasswd
  68 file here.
  69
  70 Since Apache is not in the project groups, there is a special cronjob run
  71 every minute to fix up the permissions for the refs/, info/, and objects/
  72 project directories, under the root user.
  73
  74
  75 Mirror mode
  76 -----------
  77
  78 To keep things safe and neat, repo.or.cz is job-controlled: the only thing the
  79 cgi script does is scheduling a clone job (by creating a directory with some
  80 files at a magic location) and then the clonecheck.sh script is invoked every
  81 minute by cron (under more reasonable uid) to check if there are any jobs
  82 scheduled, and calls clone.sh to do the clone itself, notifying the user about
  83 the results.
  84
  85 The script that keeps repositories up-to-date is updatecheck.sh, being run
  86 by cron every hour and calling update.sh for all the relevant repositories.
  87
  88 updateglibc.sh stands somewhat out of the crowd and keeps the Git mirror of
  89 the glibc CVS repository up-to-date, so it's probably not interesting for
  90 anyone.
  91
  92 To make sure a project is not pushable when in mirror mode, the last colon
  93 in the /etc/group entry for the project is doubled.