Well, in Fact, it's probably just a *preliminary* Summary. I asked:
> Folks, I'm pretty sure that someone already did this, but I can't find it ...
> My Users have asked me that I should inhibit fingerd giving out "sensible
> Information". However, I'ld prefer not to turn it off completely (netfind
> is sooo useful :-), but then I have to hack it. What I would like to do is:
[Different Results for different Network "Distances"]
> What I would like even better is that the fingerd determines a "Distance"
> (local Host, our Cluster, Subnet 126.96.36.199, Net 188.8.131.52, Rest of the
> World) and looks up a File given by the User to tell what Info is to be
> given ... but that's a little much, I'm afraid. (Could I install several
> fingerd's and let a tcp Wrapper call up the one appropriate for the current
> Meanwhile, I had a Look at GNU finger (too big a Hammer, and it doesn't shut
> the Holes close until the User creates a ~/.fingerrc) and at the low-Cost-
> Solution "mv /usr/ucb/finger /usr/bin", but both fall a little Bit short of
> what I imagined.
Two People suggested TCP Wrappers. The newest Version allows to replace
the Daemon supposed to answer the Request with a Program whose I/O gets
connected to the requesting Network Connection. Mike suggested incorpora-
ting a simple "Not invented here" into a custom fingerd, which is more
prohibiting than I'ld actually like Things to be. James pointed me to some
additional finger[d] Sources. However, after having read some more FM's,
I've been bitten by the Fact that you can do
which then appears to kleopatra.uni-trier.de as coming from claudius.
Thus, my Odds are: Either give up REAL Functionality (multi-@ Requests)
or treat ANY Request as (possibly) remote. Sob. I'll probably install a
privacy-conscious fingerd on the standard Port and a full-blown, within-
our-cluster-only Version on some custom Port.
Butch Deal <firstname.lastname@example.org>
Dan Stromberg <email@example.com>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:33 CDT