Thursday, June 27, 2013

Failing (but learning?)

The last couple of evenings have been frustrating. I've been trying to figure out LDAP (Lightweight Directory Access Protocol) for a testing/development environment I'm building at the moment. Basically, what Windows calls Active Directory and Mac OSX calls OpenDirectory. In other words, horrible infrastructure stuff that us mere mortals shouldn't really have to worry about.

My main problem with it is that it's just really amazingly horrible and there seems to be very little "for beginners" kind of documentation out there. So I can set a up a server! Yay! Only... then you have to load it up with information. How do you load it up with information? You create a file with this sort of information:

 dn: ou=People,dc=example,dc=com  
 objectClass: organizationalUnit  
 ou: People  
 dn: ou=Groups,dc=example,dc=com  
 objectClass: organizationalUnit  
 ou: Groups  
 dn: cn=miners,ou=Groups,dc=example,dc=com  
 objectClass: posixGroup  
 cn: miners  
 gidNumber: 5000  
 dn: uid=john,ou=People,dc=example,dc=com  
 objectClass: inetOrgPerson  
 objectClass: posixAccount  
 objectClass: shadowAccount  
 uid: john  
 sn: Doe  
 givenName: John  
 cn: John Doe  
 displayName: John Doe  
 uidNumber: 10000  
 gidNumber: 5000  
 userPassword: johnldap  
 gecos: John Doe  
 loginShell: /bin/bash  
 homeDirectory: /home/john  

And then run a command such as the following on it:

ldapadd -x -D cn=admin,dc=example,dc=com -W -f add_content.ldif

Yuck. That looks like one of those sorts of usability things that I'm always whinging about. Reading that, I can figure out certain things. For example, the first bit creates a people.... structure? Your users live in there. On a Linux system, that would be /etc/passwd file. Check. Learnt something. The next bit, you create a groups structure. Again, just like your /etc/groups file. Brilliant. I'm getting somewhere! And then we create a posix group - so an actual group to go inside of that groups structure called miners. This is called miners. So we have:

 └── example
        ├── Groups
        │   └── miners
        └── People

It all looks all nice an hierarchical. I can make sense of this. Sort of. The rest of it, we create a user. In Linux, this is a single line in /etc/passwd (and another similar line in /etc/shadow):

john:x:10000:5000:John Doe,,,John Doe:/home/john:/bin/bash

John is a member of the miners group (Look see? You only have to notice the group id number. It's simple right?). I have no idea how I'd apply a secondary group i.e. on most desktop systems, new users are given their own group and additional groups (for things like accessing the cd rom for example).

So hey, I'm learning something. Only... the details elude me. See those codes? cn, sn, ou etc. What do they all mean?

A friend showed me an email thread he'd been involved with in which to update a website the maintainer told him he had to do a "git push". The question was quick and obvious. "What's a git push? It's not pushing annoying people down the stairs is it?". Anyway, it all ended with the maintainer saying something about CMS's. I told this friend that he should have asked if CMS stood for "Concurrent Merge System" - how is it different from git?

Abbreviations are generally a good thing except when the speaker expects everyone to know what those abbreviations mean. I've seen some people who continually use TLA's (Three Letter Abbreviations) to the point that you just stop reading the emails because you're well and truly sick having to look up the abbreviation and then try and figure out which one they mean based on the context.

Anyway, a quick search on the Internet, and I find someone who's asked exactly the same question. Which then leads me to a site with the answers.

Right... sod all of that. It's dumb. For starters, I wouldn't want to fire up a text editor every time I wanted to change something and then have to run a command on whatever file I created. And who the hell wants to specifically keep track of group id's and user id's? System admins are people too dang nang it!

So surely someone's made a nice GUI for it. And hey, it's a network administration thing so it should be web based right? It's open software so there's no issues with trying to sell administration packages or anything. Sure enough, I found one called GOsa. From the screenshots, it ticks the boxes. And hopefully it understands that when I add a user, it should have a bunch of predetermined fields. Hell - it should just look like your standard user management on a Linux system. Nice and easy.

All I've got to do is install it, point my browser to it and follow the on screen instructions. So... three deep breaths and on into the breach! It's looking good! I ascertain there's an admin ldap user so enter it's credentials in. Everything is looking green. And then it tells me that the admin user doesn't have the rights to be able to write to the LDAP database.

2 a.m. and I'm feeling really lost. Why wouldn't an admin be allowed to edit the LDAP database?

A bit of search eventually finds me this little passage:

there is no administrative account created for the slapd-config database. There is, however, a SASL identity that is granted full access to it. It represents the localhost's superuser (root/sudo).

Wait... no administrative account. What the hell is an "SASL identity"? And why did the installation ask me for a administrative password if not to create an administrative user? Is this like a root thing? Can I get around it by running a one liner? i.e. assigning a password to root? Argh! I'm so confused...

Okay... 3 more deep breaths, so read the documentation more carefully. Surely, if I have a user - admin - who can authenticate with LDAP, then it's just a case of granting permissions to that user. Which means I'd also have to learn ACL's (Yuck). The tutorial I've been reading has a section on ACL's but doesn't say anything about how to alter them.

This feels like a hell of a lot of effort to not have to learn all of this and gain a level of abstraction on it so that I'm able to do very simple things. And this is just setting up LDAP. This isn't yet getting a client to authenticate to it. It's 3 a.m. on the second evening of this....

Now I feel like I've hit a wall. I only want to be able to do a few simple things with a nice simple interface. The funny bit though - I've learnt a hell of a lot about LDAP. I've failed. I'm asking for help (and no one on the mailing list I've asked on has come back with a response). I don't know how to proceed. I know the UI (User Interface) is there so making it work should be the hardest thing about it... so I'm loathe to go back to editing files.

The failure in and of itself has had me learning more. I've gone back and figured out what all that cn, sn etc. stuff is. I've learnt that there's an admin account that can't do anything (why?!?) - who's not really a real user. I'm probably going to spend a crapload of time learning ACL's.

There's so much more learning (though often frustratingly so) to be done through failure...

No comments:

Post a Comment