Pulling code from replication server - user verification?

[Brad Larson]

We have an off-site group which is working on code with a gerrit
server at the head office. Bandwidth is limited between the group and
the server. To speed up syncs, we have a replication server at their
office which gerrit pushes to, and they pull code from it.

I've been handling user authentication with gitosis on the replication
server. I'd really like to upgrade and do checkouts straight through
gerrit. The dual-maintenance of ssh keys is a pain, and with Shawn's
ldap script it would eliminate all user administration(!)

Is there any way to have the off-site group still pull code from the
replication server, but still authenticate with the gerrit database?
If not, how feasible is it to add something like this? Will this be
easier once the database lives in git?

Thanks!
Brad

[Shawn Pearce]

You need to hack a few things in the code.  I've wanted to do this myself for some time, so if you can hack it and submit a patch back, I'd appreciate it.  :-)

Basically, idea goes like this:

Gerrit already has a daemon command that starts with "java -jar gerrit.war daemon".  It fires up the SSHD, but no HTTP container or anything, and responds to commands on the SSHD just like Gerrit normally would.  You could run this on the replication slave.

However.

This also fires up the submit queue during startup, and the mirror sync queue.  These are started implicitly because Daemon.java calls GerritSshDaemon.startSshd, which in turn calls GerritServer.getInstance(), which has startQueues = true.  On a slave we can't permit these queues to execute.  You need to modify the code to ensure the queues aren't started from this daemon script.

The daemon also accepts uploads of new changes.  You can't do that on the slave, as the master wouldn't have the data.  So you need a command line option (e.g. "--slave") that tells it to either disable "git-receive-pack" and "gerrit-replicate" in the GerritCommandFactory class, or you need to provide stub replacements for these that know how to tunnel to the master.  (If you do the latter than uploading to the slave just forwards to the correct server transparently, but its a lot more code to write, its easier to just deny the commands on the slave.)

You need to use GerritServer.properties to setup the database connection, and you would need to talk to the master database directly, which potentially means using SSL if you don't want the database password running in the clear on the wire.  I have no clue how to setup PostgreSQL's SSL connection stuff.  :-)

Actually, that's about it.  The big thing is disabling the two things (queues and receive-pack/replicate commands) a slave can't do.

And yes, once the database is in git, the account data and ssh keys will be too, which makes it easier to replicate that to a slave.  But we'd still need a "daemon --slave" flag to tell it not to permit writes here, because its only a mirror.  Later, if we can get bi-directional replication working, we could lift that restriction, allowing those users to write locally, and let Gerrit replicate over the WAN.

[Brad Larson]

Sounds great! I'll look into a --slave option, and will just disable
uploads for now.

Should the submit and mirror sync queues never be started for the
daemon, or just if the user passes in the --slave option?

On Jun 5, 11:05 am, Shawn Pearce <s...@google.com> wrote:

[Brad Larson]

This issue is now tracked in http://jira.source.android.com/jira/browse/GERRIT-216

[Shawn Pearce]

Disable only on --slave.

On Jun 7, 2009 8:08 PM, "Brad Larson" <bkla...@gmail.com> wrote:


Sounds great!  I'll look into a --slave option, and will just disable
uploads for now.

Should the submit and mirror sync queues never be started for the
daemon, or just if the user passes in the --slave option?

On Jun 5, 11:05 am, Shawn Pearce <s...@google.com> wrote:

> On Fri, Jun 5, 2009 at 08:38, Brad Larson <bklar...@gmail.com> wrote: > > > We have an off-site gr...

--~--~---------~--~----~------------~-------~--~----~ To unsubscribe, email repo-discuss+unsubscribe...