Re: inetd improvements [gsoc16]

[christos%astron.com@localhost (Christos Zoulas)]

In article <op.ydn26ms65znmjo@fennec>,
Morgan ``indrora'' Gangwere <morgan.gangwere%gmail.com@localhost> wrote:
>
>targeted at christos mostly.
>
>I saw the GSOC posting that inetd needs some love.
>
>About me: I'm a student at the University of New Mexico. I'm not afraid to  
>dig my hands into a codebase and fix things, add things or otherwise get  
>work done. My projects have primarily been "Take this existing thing and  
>fix this annoyance with it". I've gotten my hands into a variety of BSDs  
>and *nixes (I even experimented with NetBSD back when I was using a Zaurus  
>for a while). I maintain a tiny linux container to get used to small  
>environments at < zaibatsutel.net >
>
>I have a (vaguely) self-serving reason to work on inetd: I use it. In  
>several simple systems, I use NetBSD's inetd to serve simple shell-script  
>based services.
>
>I think the per-service configuration might be the first thing to handle,  
>however. At the moment, the "best" way to implement adding configuration  
>for rate-limiting and friends would be to hijack part of inetd.conf  
>(probably adding options to proto, making config syntax something like  
>"tcp4,limit=10,20" for 10 invocations in 20 seconds, and potentially to  
>progname, meaning ssh,prefork=2 would keep 2 children waiting). On one  
>hand, it's historically consistent: adding more options is a time-honored  
>tradition. On the other hand, it's starting to show its age. Potentially  
>making /etc/inetd/(service).conf or /etc/inetd.rc hold things is a better  
>idea? I'd like to see what old UNIX admins with graying beards have to say.

Yes, I think that a per-service file with better syntax is probably the way
to go. I think that it is not worth enhancing more the existing syntax. If
you need new features, use the new way. Perhaps have a /etc/inetd directory
for the system services and a /var/inetd for the user requested ones.

>On a process related note, I have a few questions:
>
>  * Where can I find a style guide? (Obviously, I want^H^H^H^H need to keep  
>my contributions in KNF)

http://nxr.netbsd.org/xref/src/share/misc/style

>  * I'm not totally familiar with working outside pkgsrc -- Is there a  
>wikipage on building the system bits of netbsd?

You can check out the source tree and then run a build using build.sh.
This works on non-netbsd systems too. There is a BUILDING file in the
top level directory

>  * What sort of work has been done on inetd in the past?

You mean by other OS's? The other thing to look at is launchd which
is a superset of the inetd functionality (supporting dependencies etc.)
Perhaps even replacing inetd with launchd.

>  * What sort of plan does the NetBSD project have for the future?

For inetd or in general? See above.

>I've noticed that a lot of tools in usr/sbin are kept in big, monolithic  
>slabs. I understand this is because of historical reasons, but is there  
>any plan to move ahead? Would inetd be a good place to start splitting up  
>these hulking 2k sloc behemoths?

Give some examples of which you would like to split and into what...

christos