bug-inetutils
[Top][All Lists]
Advanced

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

Re: inetd


From: Jeff Bailey
Subject: Re: inetd
Date: Mon, 2 Sep 2002 08:58:53 -0700
User-agent: Mutt/1.3.28i

On Mon, Sep 02, 2002 at 11:29:58AM -0400, Alain Magloire wrote:

> > The inetd stuff I want to do is just rewriting it so that it's all
> > copyright the FSF.  I figured it's an easy place to start.

> Ok, but you probably wants a list of features, that the new should/must
> supported:

I'll be committing a file 'TODO' as soon as the release is out.
Please feel free to add/modify it.

> - The current inetutils/inetd reads snippets from inetd.d/*, the
> same thing that xinetd does but the snippets are inetd.conf formats.
> Xinetd uses a different format.  I suppose it could b e possible if
> the code is modular enough to load different

I haven't finished thinking about this.  I want it to do xinetd like
stuff from things in this directory, but I don't know that I want to
commit to tracking any changes to the format that xinetd does.  It
might be better to make it gratuitously incompatible so that there are
no promises.

> - xinetd does all sort of filtering a la tcpd, for example:
>    * restriction on time of access
>    * restriction on ip address, name, domain etc..
>    * binding of specific IP

> The filtering restriction could probably be in a different lib
> instead of bloating inetd.  I think "tcpd" comes with a library.

Is it bloat?  That seems the core functionality of inetd. =) Of
course, if it can be usefully shared with other inetutils apps, it
makes sense to librarify it.

I do plan to split out some of the basic tcp service (echo, chargen,
etc...) into separate executables.  Those seem like not-core-services
to me.

Tks,
Jeff Bailey

-- 
At last you cry out in anguish: "Why me?"
God answers: "Why not?"
 - Sheldon Kopp




reply via email to

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