[Top][All Lists]
[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?
- inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois, Jeff Bailey, 2002/08/02
- Re: inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois,
Jeff Bailey <=
- Re: inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois, Jeff Bailey, 2002/08/02
- Re: inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois, Jeff Bailey, 2002/08/02
- Re: inetd and whois, Alain Magloire, 2002/08/02
- Message not available
- Re: inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois, Jeff Bailey, 2002/08/02
- Re: inetd and whois, Marco d'Itri, 2002/08/02
- Re: inetd and whois, Alain Magloire, 2002/08/02
- Message not available
- Re: inetd and whois, Marco d'Itri, 2002/08/02