Just a trivial observation we noticed here at RPI. This is just
for your amusement. There is nothing important about it.
This past weekend we (RPI) had some odd problem pop up. The problem
itself has no connection to OpenAFS, but while investigating that
problem the guy who runs our LDAP servers noticed ldap queries of:
(&(objectClass=ipService)(cn=afskauth))
or (&(objectClass=ipService)(cn=afsprot))
We were often seeing about 30 of those in a second. It wasn't every
second, but these bursts happened many times per hour. And on rare
occasions we'd also see a lot of:
(&(objectClass=ipService)(cn=afsvldb))
Like maybe 60/second for 30-45 minutes, and then none of these afsvldb
searches will show up for days.
None of this is a problem for us or our LDAP servers (and they have
nothing to do with the problem we actually care about), but we got
to wondering where these requests might be coming from. It turns
out the culprits were two very old linux machines we have, running
a very old (2004!) version of OpenAFS. And someone on our staff
had an automatic process which monitored those machines by doing
many 'ssh' commands into them. 10-15 different commands, done via
separate 'ssh' connections, and all done at once. And then repeated
every 5-10 minutes.
Apparently this ancient version of OpenAFS will first search for AFS
services via the original names of afskauth and afsprot, even though
/etc/services on those machines had the newer and official names of
afs3-kaserver and afs3-prserver. Those ancient names are so old that
I didn't even recognize them! I eventually found them in listed in:
http://www.mit.edu/afs.new/athena/system/pmax_ul4/srvd/etc/services
along with afscb and afsvol.
And to top it off, these ancient linux machines had /etc/nsswitch.conf
configured so that "services" would be looked up in both "files" and
"ldap". I have no idea why /etc/nsswitch.conf was set up that way
on these machines. I deleted "ldap" from that line, rebooted, and it
seems like everything is still working fine. So openafs must just
look for the new service names after failing on the ancient names.
(note that our LDAP server certainly never had the ancient names!)
And based on https://tools.ietf.org/html/rfc1340 , it looks like the
"new" service names were officially added between 1990 and 1992.
I have no "to-do" request here. I just thought this was amusing.
And the final irony is that these two ancient linux machines are
already scheduled to be replaced this month, or maybe March at the
latest. So these LDAP searches have been going on for 13 years
without anyone noticing them, and then they were finally noticed
just weeks before the problem would have disappeared.
I'm hoping that this writeup might help someone in the future who
comes across LDAP queries like these at their own site, and tries to
google for "ipService" and "afskauth" to figure out what is going on!
--
Garance Alistair Drosehn = dro...@rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY; USA
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
