bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inetd and whois


From: Jeff Bailey
Subject: Re: inetd and whois
Date: Fri, 2 Aug 2002 09:32:23 -0700
User-agent: Mutt/1.3.28i

On Fri, Aug 02, 2002 at 06:18:50PM +0200, Marco d'Itri wrote:

> 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?

What does it do?

>  >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.

Sure, but netkit doesn't run on BSD or the Hurd.  Inetutils already
runs on all of these.  I'm hoping that Inetutils will have the
required features within a year.

>  >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 do not see the point of this. Most of these cases are different
> enough that little or no code can be shared.

The point is that between mailutils and inetutils, we have a dozen
programs that need to share this.  I want to hand off to a function
call that returns me file handles to work with.  I shouldn't have to
worry about how I got there.

>  >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.

I haven't and I can't if I want to be able to code this.  Is there a
public API reference?  I don't object to working from that.  If there
isn't an API reference, then I may as well get started on this.

>  >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.

So would it go in the startup library as an option for network-based
communication?  Not all daemons start as part of inetd.  I have an
intense dislike for inetd and think it should not be required if all I
want is telnetd.

The problem with inetd is that things start to creap into it, so it's
hard to notice.  But I do ``ps -ef'' very often.  I notice if there's
programs running that shouldn't be.

Tks,
Jeff Bailey

-- 
I reincarnated for this?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]