I admin the AFS cell for a college-level cell at a large university. :-)

I recently had an off-list discussion with someone regarding the futures of OpenAFS. I happened to mention that I wrote a collection of scripts that scrape my campus's LDAP directory to keep PTS in sync with it. Generally querying LDAP and:

 - discovering new users and creating PTS entries.
 - discovering former users and initiating grace period tracking.
- creating and populating homedir volumes if a user is within my College and lacks one. - discovering and fixing up groups and volumes for users with newly-changed usernames. - adding users to and removing users from PTS groups based on users' department(s) and classification(s). - deleting former user's PTS entries (and groups) (after the grace period). - archiving and deleting former users' volumes (after a grace period) for former users.

...this basically handles a lot of the drudgery of what used to be manual processes, and keeps PTS's state in sync with the reality reflected in LDAP. It's been operating for almost 2 years so far, with a few bug-fixes.

An example:
pts mem johndoe | grep unc:
  unc:111111-spa
  unc:111111-employees
  unc:111111-all
  unc:cas-spa
  unc:cas-employees
  unc:cas-all
  unc:spa
  unc:employees
  unc:all

Where johndoe is an SPA employee in department number 111111. In this case dept 111111 is a dept within the College (cas).

A slightly more complex example for a faculty with dual appointments:
pts mem janedoe | grep unc:
  unc:222222-retiree
  unc:222222-associates
  unc:222222-all
  unc:cas-retiree
  unc:cas-epa_faculty
  unc:cas-associates
  unc:cas-all
  unc:333333-retiree
  unc:333333-associates
  unc:333333-all
  unc:retiree
  unc:epa_faculty
  unc:associates
  unc:all

Finally, here's someone in a department that's not part of the College:
pts mem billybob | grep unc:
  unc:444444-epa_non_faculty
  unc:444444-employees
  unc:444444-all
  unc:epa_non_faculty
  unc:employees
  unc:all

Some state information is kept in PTS (in old:* groups). But state information with a temporal component (former group membership for when users change departments, change username, or leave the university) is kept in dated flat files rather than any sort of database. This has pros and cons.

The sync scripts are written in perl and usually take 1-3 hours each day for my site's cell. It only takes this long because I do PTS operations atomically to track results. For reference, here's the scope of my site:

 "university" pts users (for use on ACLs): ~35K
 "college" users with homedirs: ~13.5K
 unc:* groups maintained: ~6,300

Unfortunately, what I have would not be a turn-key solution for other sites because it makes some assumptions about users' affiliations based on information UNC has in its LDAP schema (and the different attributes for different types of affiliates).

In the interest of full disclosure, I'm a sysadmin, not a programmer. So currently the code that I have is "good enough." I never really anticipated distributing it.

Nevertheless, I thought I'd see if there would be any interest in such a collection of scripts if I cleaned them up a bit - removing any sensitive bits - and released them under the GPL. I obviously don't want to go to that trouble if no one else would find them useful.

Also I don't want to discourage discussion on the list, but feel free to contact me directly to express interest if it's just a "me too" note.

Cheers,
Stephen
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to