On Wed, Dec 17, 2008 at 10:33:03AM -0800, Stephen Hahn wrote: > > It's different than it was, but I'm not sure it's more complicated. > In the interest of giving Mark source material, here's what I've done > a few times now.
Having just gone through this, I don't agree at all - if you want anything close to the ON gate. In the old world, all we had was a single gate and a notification file. Now we have a gate and a clone, a custom account, SSH access and key management, specific permissions on everything, and specific NFS export permissions on everything (particularly if your gate machine doesn't support local logins). The 'public' directory needs to be set up in a particular way or else things fail in horrible ways. You need to pull down packages from a separate tools repository, customize the gate hgrc and customize site.conf. All the hooks are tied tightly to the ON world, and require editing for hardcoded things like the 'gk' group having special privileges (and failing horribly if the 'gk' group doesn't exist). Many of these require changing not the gate hooks, but the cadmium checks that run out of onbld. Pushing batched changes from ON requires temporarily disabling sanity checks, as well as locking and unlocking the gate. All of this infrastructure needs to be duplicated for every gate. The sum documentation on all of this accounts to a single README and two blog posts. It took well over a week for me to get this set up, with copious amounts of hand holding from the gatekeepers. So I don't agree that it's less complicated, and I would greatly appreciate a TOI on "how to set up gates like we do in ON," which is what we generally want to do anyway. - Eric -- Eric Schrock, Fishworks http://blogs.sun.com/eschrock
