deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

document how to create multiple gitolite instances on one server...

Browse source 
...and provide a pointer from the delegations doc for people taking
delegation too far ;-)
This commit is contained in:
Sitaram Chamarty 2010-04-11 04:09:50 +05:30
parent e0fe73ac18
commit 4b65cc51d3
2 changed files with 44 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/0-INSTALL.mkd
View file

@ -28,6 +28,7 @@ In this document:
* upgrades * upgrades
* other notes * other notes
* system install / user setup * system install / user setup
* multiple gitolite instances
* next steps * next steps
* appendix A: server and client requirements for user install * appendix A: server and client requirements for user install
* server * server
@ -165,6 +166,28 @@ the server and run the same command as above.
`$GL_PACKAGE_CONF` and `$GL_PACKAGE_HOOKS`. If you remove or change either of `$GL_PACKAGE_CONF` and `$GL_PACKAGE_HOOKS`. If you remove or change either of
them, expect trouble :-) them, expect trouble :-)
#### multiple gitolite instances
With this mode of install, it's easy to create multiple gitolite instances
(say one for each department, on some mega company-wide server). You can even
do this without giving shell access to the admins. Here's an example with
just two "departments", and their admins Alice and Bob:
* create userids `webbrowser_repos` and `webserver_repos`
* ask Alice and Bob for their pubkeys; copy them to the respective home
directories for convenience
* run `su - webbrowser_repos`, then `gl-setup alice.pub`
* (similarly with `webserver_repos` and `bob.pub`, and so on for others)
That's it. The URL for all web browser projects is now something like
`webbrowser_repos@server:reponame`, and similarly for the others.
Notice that you only have to do this once for each "department", and it's
really just one command after creating the userid. None of these admins need
to have a command line on the server, so don't give them the passwords if you
don't need to -- the pubkey will allow them to be gitolite admins on their
domain, and that's quite enough for normal operations.
### next steps ### next steps
The last message produced by the easy install script should tell you how to The last message produced by the easy install script should tell you how to

21
doc/5-delegation.mkd
View file

@ -97,3 +97,24 @@ Naturally, a successful push invokes the post-update hook that the admin repo
has, which eventually runs the compile script. The **net effect** is as if has, which eventually runs the compile script. The **net effect** is as if
you appended the contents of all the "fragment" files, in alphabetical order, you appended the contents of all the "fragment" files, in alphabetical order,
to the bottom of the main file. to the bottom of the main file.
----
### Security/Philosophy note
The delegation feature is meant only for access control rules, not pubkeys.
Adding/removing pubkeys is a much more significant event than changing branch
level permissions for people already on staff, and only the main admin should
be allowed to do it.
Gitolite's "userids" all live in the same namespace. This is unlikely to
change, so please don't ask -- it gets real complicated to do otherwise.
Allowing delegated admins to add users means username collisions, which also
means security problems (admin-A creates a pubkey for Admin-B, thus gaining
access to all of Admin-B's stuff).
If you feel the need to delegate even that, please just go the whole hog and
give them separate gitolite instances! It's pretty easy to setup the
*software* itself system-wide, so that many users can use it without all the
"easy install" fuss. See the "system install / user setup" section in
doc/0-INSTALL.mkd for details.