We’re in this together.
The ROC is a collective activity, and this means that contributing to it should be easy and desirable. The bedrock of the infrastructure are those computational resources which deliver services to user and technical communities, and contributing to the maintenance, improvement and development of these is part of the social contract that is entered into when joining the ROC.
Contributions can come in many forms — merely talking about the ROC on the internet is a positive contribution (even if it is positively criticised). However, apart from actually joining the ROC as a site and contributing physical resources, the most concrete contribution that there can probably be is code.
AAROC ❤ Github
As regular readers know, we have kind of a love affair with Github, where one of our most important repos lives1. DevOps. It contains the code necessary to orchestrate a wide array of services, using Ansible playbooks and Puppet.
Teaching ourselves to fish
These are DevOps tools to take models of services, along with site-specific variables and orchestrates them into functional services at sites. This method allows those developing services to do so in a site-independent way, meaning that the work is re-usable. We believe that may be a much better way of contributing knowledge transfer than running training workshops which try to teach all technologies and tools to all site administrators. This allows specialisation and creates a network of collaboration and dependency that goes beyond simply asking for help. To paraphrase the good old book:
give an admin a working site and you feed his users for a day; teach them to orchestrate their site and you feed their users for a lifetime — not the Bible
… well, as long as the users are partaking of the feast that is !
Gotta catch-em all !
One of the services which the Ansible playbooks can orchestrate is the Shibboleth Identity Provider + LDAP backend for authenticating users in identity federations to web-based services — particularly science gateways. User identity in these federations2are provided by institutes, which sometimes have their own identity providers in the federation. However, it is often the case that either no federation exists or that there is no standards-compliant3identity provider. Rather than exclude users falling into this case from the usage of our science gateways, a set of “catch-all” identity providers, in the Catch-All Federation. These are a set of identity providers deployed using our fantastic Ansible playbooks which can whip you up a set of services necessary to identify “homeless”4users and allow them to join the science gateway. We have instances all over Africa and the Middle East5. Users can choose these catch-all identity providers in the NREN closest to them — which is usually at a national level, so provides pretty good coverage — and use the form to sign up. A screenshot of the one in Tanzania is below.
The registration page for the TERNET Catch-All Identity Provider in Tanzania
You’ll notice that there is a field for users to state which organisation they are from.
Case study — contributing organisations
The organisation field is a pretty big deal — we want to provide access to the right kinds of people, not just anybody. Identity provider adminsitrators have to make a quick identity check on the requestor[^trustlevel] to see whether their request is valid, and this includes having a valid organisation.
Of course, since this is a catch-all service, it is expected that there will be users from new institutes that are not contained within the initial template of organisations that the repository and playbooks provide. This template has been collected over the years, and — coming to the crux of this particular biscuit — we would like to be able to accrue new institutes into a single database. The question then is — what is the procedure for providing new institutes to the repository ?
Hint : it does not start with “send an email”
The short answer is : send a pull request. The long answer is below.
Step-by-step pull request for new organisations.
- Fork the repo to your own account
- Add your repo to the git remotes on your side : git remote add personal https://github.com/username/DevOps
- Edit the file Ansible/roles/ldap/files/etc/openldap/slap.d/orgs.ldif
- Commit the file and push it to your personal repo : git commit Ansible/roles/ldap/files/etc/openldap/slap.d/orgs.ldif -m “New organisations” ; git push personal master
- Go to your repo on github and open a pull request (the green button that looks like a recycle).
- Select @AAROC/DevOps as base fork and your repo as the head fork Send pull requests to the dev branch of @AAROC/DevOps You need to do this across repos you should see only one file changed (the file you’ve just created)
We’ll then discuss the new additions and hopefully add them.
So, let’s keep adding flavour to the pot and get a whole bunch of work done in the meantime
Originally published at aaroc.github.io on June 4, 2015.