Staging gitolite (draft)

[Ted Hess]

Jow -

> We cannot use the current 'git' user and /home/git on ff0 (git.lede-project.org)
> > as currently configured. I can either create a new user for gitolite or re-work
> > the current 'git' account to conform to gitolite requirements.
> 
> I'd favor reworking the existing account to meet the gitolite requirements.

No problem - I'll setup a new temp account and then flip it to 'git' and import the
repos, fixup permissions, ownership, etc. Note: the only real significant difference
will be the replacement of the .ssh/authorized-keys file. 

> > After switching over to gitolite, there will be SSH access to the 'git' user for
> > purposes of gitolite management and repo access under gitolite ACLs. SSH access
> > control to gitolite requires a gitolite user-id (not a system user-id) and a
> > public key setup.
> > 
> > gitolite management is through the gitolite-admin git repo via git access to the
> > admin acct/group (seems a bit recursive). If there is interest for the ability
> > to create git repos remotely through gitolite, it is possible to grant that
> > capability to selected users. 
> 
> Having that self-service capability would be great, considering the fact
> that we wanted per-user staging repos.
> 
> > HTTP/HTTPS read-only access will continue to available via gitweb/nginx as now.
> 
> Great.
> 
> > Deployment plan:
> > 
> >    1. Install gitolite3 on ff0 from Ubuntu dist (or from source if necessary)
> >    2. Import current LEDE git repos into gitolite3 (temp for testing only)
> >    3. Setup gitolite members, users, notifications.
> >    4. Enable gitweb/HTTP access
> >    5. Test (volunteers?)
> >    6. Schedule downtime to switch over to the live repos (re-import current
> >       versions) and gitolite accounts.
> 
> That sounds good to me, what would be the best time for you to do the
> switch? Can we somehow take an existing gitolite installation and switch
> it to another uid or do we need to rebuild the setup from scratch?
> 

I can setup the gitolite stuff later today and it should be live sometime
tomorrow. I'll send out a preliminary access config list. I need user-names
and ssh pubkeys for folks who have non-readonly access. I think I can rework
the keys you already have setup. 

Things may be a little more open that we want initially. I'll tighten things
down as we go forward. We may want to differentiate between those who have
write/commit access (ff-only) and those who have delete/rewind/tags/branches, etc.
 

> > To Do:
> >  * Investigate/setup HTTPS access with  authentication through gitolite
> >    ACL control (if desired).
> 
> I don't think we need that - imho the HTTP/HTTPS transport should only
> be used for anonymous and readonly cloning.

Good - I didn't want to setup HTTP auth.

> >  * Setup ability for sending automatically genererated emails per repo.
> 
> I suppose we need an SMTP smart host for that? There is none right now
> but we could just use a gmail account.
> 

Yup - either.

> >  * Enable and configure other desired gitolite features.
> 
> We'll see what features we could use once the base system has been set
> up but I think the core feature set already covers most of our use cases.
> 

/ted