During the recent LoPSA live chat on #lopsa-live it was mentioned that there weren’t enough topics for people to write about on the website and how it was harder for people to come up with an interesting topic than it was to actually write about that. That inspired me to finally draft a proposed series of topics based around the notion of “Scaling Up”; something that’s been bouncing around in my head for a few years.
!! Motivation
We spend a lot of effort building and describing tools and techniques – the craft of system administration. A precious few tomes reach beyond the command line to discuss the practice of system administration (I’m thinking specifically of the works of Tom Limoncelli & Christine Hogan.) What I’m searching for is a bridge between the two topics – what you want to eventually achieve and why (practice) and how you can actually achieve that (craft.)
! LDAP
I’ve been trying to understand how to “properly” set up LDAP for around 6 years now. Not “How to install and configure OpenLDAP” and not “Why you want an LDAP server” but “How to organize and centralize personal and machine data to simplify authentication and avoid error and redundancy in a simple and extensible manner.” I know that sounds like wishful thinking, but I find it helpful to condense what I want in a single sentence.
Bear with me – this gets a bit touchy. I’ve installed OpenLDAP before – from source, RPM, and deb packages. That’s not a problem; there are plenty of packages and tutorials that address installation. I know ”why” I want a LDAP server – I don’t want user and machine data squirreled away on each machine because ”it doesn’t scale”. I want to get out of the habit of building one-off machines and spend more time working real problems. So the problem is not setting up an LDAP server, the problem is __organizing the data__.
LDAP is a shining example of a machine-oriented (bad) solution. Meaning it works in theory but is prohibitively difficult to put into practice if you’re a novice. The party line when seeking advice on organizing one’s data is that each organization is different so a generic approach is not possible. Translation: there is no “Best Practice” that anyone is willing to talk about.
I agree with the premise but dispute the response. Organizations change, thus a directory must adapt to those changes. Therefore there must be a generic starting point from which an organization-specific directory may be developed, otherwise LDAP is fatally flawed by requiring perfect knowledge at the outset.
I’m lucky. My workplace uses LDAP and I can see how they’ve organized their data and judge whether that’s appropriate for my situation (in this case, providing web services to a local theater community.) But as I see it, that’s just the tip of the iceberg. The problem is that there are problems that I know I will face as well as some that I haven’t imagined yet, and I know there are (or might be) tools to solve these problems, but there’s no effective documentation on how to use these tools or how they relate to each other. And working as a sole departmental admin in a medium sized shop with low turnover, there’s really nobody I can tap locally to find out what I want to know.
! The bigger picture
Abstracting this, I want to see a coherent edited series of articles on “scaling up.” Personal issues with LDAP aside, I want to see the migration path between one person administering 1-10 machines and two people administering 20-100. While the particulars of a technology are important (”e.g.” why you want to use Kerberos 5 instead of Kerberos 4), what may be more important is why you want to use Kerberos and how you set it up, and further, all the intervening motivations and technologies.
As I see it, they can all be related in a narrative arc, starting with a few machines managed by a single overburdened junior admin, and ending with a secure, scalable architecture managed by a few experienced admins.
In my next installment, I’ll go into more specifics about what articles I want to read (implying that someone needs to write them) and show how the technologies and practices interrelate.