Re: [RFC] inetd(8) changes proposal

[tlaronde%polynum.com@localhost]

Le Thu, Jun 01, 2023 at 12:50:30PM +0930, Brett Lymn a écrit :
> On Wed, May 31, 2023 at 12:43:40PM +0200, tlaronde%polynum.com@localhost wrote:
> > 
> > And I think you're right: the info will go in a 0400 file in /tmp, and
> > will be a way to obtain various running infos---but for now, just the
> > running config (it could perhaps be extended, but not now, to add
> > stats, what is masked by a secmodel etc.)
> >
> 
> There was a GSoC project last year that was looking to extend inetd.
> Unfortunately, it is incomplete but one of the things that was done was
> to write a inetdctl that could, among other things, dump the running
> configuration.  You may be able to use some of that code.

Thank you for the info.

But for now, it will be far simpler to only modify the NetBSD source
without trying to merge something external.

In fact, what I'm going to do is not very difficult.

And, from an engineering point of view, the problems now present are the
consequence of putting a new syntax without realizing that it totally
changes a fundamental implicit assumption: every directive in the
conf file (legacy version) was totally distinct from the others, so
failing to parse a directive was only impacting _this_ service and could
not impact others.

So it was safe and indeed logical to continue, precisely as to not
impact other services because one blunder for another service.

So, since I have now a quite clear vision of what I have to do and want
to obtain, it would be unwise to try to master or to incorporate a code
made with another vision. It will simply harden my task and risk
introducing by the window bugs I want to put out by the door.

Let's put the code right again. A side effect will be that it will be
easier to extend.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C