Re: inetd tests failing

[Solomon Ritzow <solduck%gmail.com@localhost>]

I guess looking at the test output again, it looks like inetd isn't
reading the config file (inetd_ratelimit.conf) properly. Notice the
lines that say "FREE", meaning it deleted those services. I think
what's going on is you have the current version of inetd installed on
your machine, which is what the test cases run, but are running the
tests for the next version (the one my senior project group
implemented). The config file used uses the new config syntax my team
implemented, so current inetd gets confused by it. You'll have to go
to the usr.sbin/inetd source directory and do "make install", which
will replace the program that's installed (and runs at startup on your
NetBSD machine) with the newer version. The ATF tests are intended to
test the current system, instead of the source code, unfortunately, so
that's why the program has to be installed (and you can see that I'm
calling posix_spawn with program argument "inetd" (as in the one
that's on the PATH of the system).

> but I don't think simply linking with libblocklist will add that support?

Looks like you already know more about libblocklist than me 😆.

On Mon, Mar 14, 2022 at 4:24 PM Arjun <ccldarjun%icloud.com@localhost> wrote:
>
>
> > I wrote t_inetd.c as part of my senior project for college six months
> > ago (as part of implementing some of the "inetd enhancements"
> > project).
> > It's most likely my fault it isn't working. t_inetd.c is quite fragile
> > since it just uses a range of ports on the host machine.
> > You could try checking if any of the TCP or UDP ports used in the test
> > are in-use on your
> > computer before the tests are run. I can also look into improving the
> > test. But you can probably just ignore it for now.
> The ports open on my laptop are 111 999 1017 1021 1023 2049 2222 51067 55780 59043 62799.
> These dont seem to be in the test. Could you run the test on your end?
>
> > I think the "blacklist daemon" (now called "blocklist" in the next
> > version) support might have been implemented as a single line in the
> > Makefile (in this commit:
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/inetd/Makefile?rev=1.24&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
> > ),
> > but I could be completely wrong. Maybe you've already talked to
> > Christos Zoulas, but I think he would be the person to talk to for
> > that.
> I haven’t, yet, talked with him but I don't think simply linking with libblocklist will add that support?
> I grepped for the blocklist functions (https://man.netbsd.org/NetBSD-9.2/blacklist.3 these are to notify
> the blocklist daemon) in inetd source files and didn’t find any matches.
>
> > My senior project group didn't get around to implementing
> > "pre-forking", so that should be interesting to implement! Here's what
> > Christos had
> > to say about it: "Means that once a preforked child is done you can
> > either wait(2) for it and end it or you can put it back of the list
> > of available processes so that it can handle more requests." It's kind
> > of a confusing concept to me!
> Yeah, it does seem confusing to actually implement.
>
> - Arjun
>