Re: inetd and whois

[Marco d'Itri]

On Aug 02, Jeff Bailey <address@hidden> wrote:

 >Someone mentioned to me the other day that GNU seems to have 3 whois
 >clients: The old one in inetutils, yours, and jwhois.  I think it's
 >easy to say that the old one should be tossed.  Have you and Jonas
 >ever spoken about combining efforts?
I think I did when he started writing his client, but just by looking at
the sources of both I think you can understand why this is not possible.
My program is simple and small, his own is bloated.

BTW, the debian whois package comes with a mkpasswd command I wrote, can
you help finding a home for it in inetutils or in another GNU package?

 >I had hoped to package this release before my vacation, but I won't be
 >able to do it now until I'm back.  I want to slowly get this one up to
 >shape to where Debian (and other distros) can consider throwing out
 >netkit.
My opinion as a developer is that debian is not even going to consider
replacing anything with inetutils until its code will be better than the
other alternatives (and still be compatible with them).
It's not like there are no free implementations of network daemons.

 >> I want it to have most of the features present in the openbsd and
 >> freebsd ones, like per-IP rate limiting, binding to specific
 >> addresses and IPv6 support.  I'd like to contribute my work to
 >> inetutils, but I'm not sure that the current code base is the best
 >> one to start with.
 >It's absoluetly *not* the right code base, with the exception of the
 >libraries that some folks have already rewritten.  I'm hoping that
 >within the next 2 releases that we will have removed all non-FSF
 >copywritten code for inetutils.
Writing a new program from scratch is not what I had in mind and given
my limited time I cannot commit to this. Looks like I will update the
netkit code or port the openbsd daemon and debian will use it until
inetutils will have comparable features.

 >1) Generic startup library.
 >
 >This library is intended to cover all of the 'startup' cases that
 >something might have to deal with.  Specifically:
 >
 >i) Running from inetd.
 >
 >ii) Running from command line.
 >
 >iii) Standalone single server
 >
 >iv) Standalone forking (and pre-forking)
 >
 >v) Standalone threaded
 >
 >vi) MS-Windows Services.
I do not see the point of this. Most of these cases are different enough
that little or no code can be shared.

 >2) Generic authentication library.
 >
 >This library would handle as many authentication cases as possible:
Do we need yet another incompatible API? I don't think so. Did you look
at the bsdauth code? I remember reading good things about it.

 >vi) (Would SSH's priviledge separation go here?)
Not at all.

 >I can see how this model would handle IPv6 and specific address
 >binding.  How would you refine it to support rate limiting?
It's just a small part of inetd.

-- 
ciao,
Marco