The Life of a Sysadmin

At $WORK I've been setting up a server for a new project. It's going to be the foundation for a bunch of work that they're doing: bag o' passwords, code repository, website + wiki, email. I've been trying to set it up in such a way that a) it'll be a good foundation and b) it'll be easy for them to manage -- at least when it comes to adding/deleting/modifying users, email addresses and so on -- rather than having to come to me every time something needs changing.

I set up CentOS Directory server and populated it with the root and a few entries. Thus: cn=Me,ou=People,dc=example,dc=org. I've got authentication working, restricted to certain groups where necessary, and now it's time for me to think about how the non-propellerheads are going to manage accounts. That means a web front end, and I've been evaluating GOsa for the last week or so.

The good:

• It's nice-looking. That's not damning-by-faint-praise; whatever I give to people is going to need to look professional.

• It's got plugins for lots of different things: Samba settings, email settings (including easy vacation settings...nice), ACLs, FAI, Nagios (which, near as I can tell, is generated from FAI info), FTP quotas, you name it.

• It supports hooks in its config file: postcreate, postremove, postmodify and check. These allow you to (say) create a home directory when a user is created or other fun things.

• It includes an easy way to manage the LDAP server: export/import snapshots in CSV and LDIF, and snapshots of the tree that can be restored later. (Haven't tried that out yet.)

• Addressbook page included.

The bad:

• The documentation can best be described as sparse.

  • Some plugins depend on others, but this isn't shown anywhere. When I tried to remove the RPMs for some that I wouldn't need, I found that others I did need failed. If it should all be installed, I couldn't find that documented anywhere.

  • Allowing people to log in to GOsa and change certain details is important for me, but is documented poorly in the ACLs page.

  • But also, ACLs can be applied only to items GOsa recognizes as Departments (ie, objectClass=gosaDepartment and/or possibly objectclass=gosaAdministrativeUnit). And you can't tell GOsa that ou=People is one of these; it complains and says that's a reserved keyword.

  • The gosa.conf config file refers you to the manpage, but that doesn't appear to be included in the RPMs I downloaded. The wiki page on the file refers you to the raw man page in the source tree.

  • It looks like vacation settings depend on an LDAP-enabled vacation responder like Gnarwl; this is cool, but wasn't documented anywhere. The only place I found this mentioned was on this blog entry, which contained a lot of other info (like how to set Postfix up; yes, I shoulda RTFM but I didn't know that Postfix could grab so much info out of LDAP) that I didn't find on the GOsa website. In fact, that blog entry was probably the best source of info about GOsa configuration.

  • Adding email information for people requires a GOsa-specific LDAP entry for a mail server; again, this is best documented in that blog entry.

• GOsa is happiest when you point it at a new, empty LDAP tree and go from there. It appears to be much less happy with the idea of pointing it at an already-existing LDAP tree (though there is support, during installation, for converting accounts it has found in the tree).

  Taking the the ou=People ACL example above as a starting point, GOsa wants to create its own department entries in your root: ou=Accounting (say), with ou=Groups and ou=People under that. I have mixed feelings about this organization; it would work well for my current employer, but I'm not sure how well it'll fit for this side project.

• GOsa makes use of GOsa-specific LDAP schemas that you add to your server; this lets it label an object with (say) notes that users are allowed to change their own password. Perhaps not bad in itself -- I don't know enough to judge -- but it seems to mean that there are two sets of ACLs to manage: those in GOsa, and those in your LDAP server.

• GOsa's schema files are for OpenLDAP syntax (there's a proper name for that but I can't think of it right now). I'm using CentOS DS, which has its own. FInding out how to convert one to the other was hard enough; after that was done, though, CentOS DS still didn't like it, and I had to delete some additional entries. There doesn't appear to be a lot of support for CentOS/Fedora/RedHat/389 DS.

  (For the record, here's what I had to do:

  $ wget http://directory.fedoraproject.org/download/ol-schema-migrate.pl
  $ for i in $(grep 'schema/gosa' /usr/share/doc/gosa/slapd.conf-example | sed -e's/ldap/openldap/' | awk '{print $2}') ; do echo ../ol-schema-migrate.pl -b $i >>  98gosa.ldif; done
  

  And then remove references to gosaLoginRestriction and goFaxDivertNumber.)

• It might be better to think of GOsa as a complete system, of which the visible LDAP front-end is only one part: as described here, it's composed of Postfix, Courier for IMAP, Cyrus for authentication, and so on. That's not entirely fair; LDAP is LDAP, and I'm sure a lot of what seems app-specific could be generified (I spik Englitch good) by configuring Dovecot (say; I already use Dovecot instead of Courier) appropriately, or writing a plugin for GOsa.

Overall, I'm not sure how happy I am with GOsa. It's not doing what I want now, and it looks like the only way to make that happen is to wipe the tree and start from scratch. -- Well, no, not scratch: create a GOsa-visible department (ou=Something) and stick everything in there. Given the sparse documentation, it's probably silly for me to focus on that, but that's what sticks out at me right now.