Staging gitolite (draft)
thess at kitschensync.net
Mon May 2 10:42:06 EDT 2016
> 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.
> > 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.
More information about the openwrt-adm