[OpenAFS] Keeping PTS in sync with LDAP
Tue, 2 Feb 2016 17:03:21 -0500
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
- 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
- archiving and deleting former users' volumes (after a grace period) for
...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.
>pts mem johndoe | grep unc:
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:
Finally, here's someone in a department that's not part of the College:
>pts mem billybob | grep unc:
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
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
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.