Some thoughts on GOsa

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][2].

* 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][6] on the file refers you to the [raw man page in
  the source tree][7].

* It looks like vacation settings depend on an LDAP-enabled
  vacation responder like [Gnarwl][3]; this is cool, but wasn't
  documented anywhere.  The only place I found this mentioned was
  on [this blog entry][4], 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][4].

• 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.