[OpenAFS-devel] Road map, was Proposal for capabilities support in Unix client 1.4.x

[Thomas Kula]

On Wed, Jun 24, 2009 at 10:13:13AM -0400, Sean O'Malley wrote:
> My apologies to the list.
> 
> But while I am thinking about upgrades and migrations is there a way to
> determine client versions that are connecting, who is using them and what
> ip they are connecting from?
> 
> If there is an upgrade from 1.4 -> 1.5 or 1.6 and client version 1.2 isn't
> supported, then it would be nice to contact the user/system admin before
> the upgrade.
> 
> A customizable auto-reply message system would be the most ideal, like a
> log, popup window and/or email message on their end to nag them a bit.
> - client too new and unsupported planned upgrade on xyz date
> - client unsupported will be deprecated on xyz date
> - client deprecated.
> - feature xyz unsupported will be by xyz date.
> - you are a security risk.
> - your client causes data and hair loss
> 
> My apologies to the list if this exists and I just missed it.

Here at work we've got[1] a script that runs rxdebug on all of
our file servers every so often, getting a list of machines that
have connections to the fileserver port. We then turn around and
for all of those machines on that list run rxdebug -version on
the cache manager port to get information about what client version
they are running. Run it every so often over a period of time
and squirrel away the data and you get a pretty good idea of what
is connecting to you.

Everything past that is pretty site-specific, though. We may have
contacted some folks in the past to try to get them to upgrade, but
I'm not sure. Once you've got a list of IPs and client versions, 
you have to figure out locally how to translate that into e-mail
addresses to bug or whatnot.

[1]: Well, it was running at one point. I think we may have turned
     it off, but at some point I may bring up just having that run
     every so often to build up some historical data, which we are
     finding increasingly useful to have.




-- 
Thomas L. Kula | kula@tproa.net | http://kula.tproa.net/