Brian May wrote: > Just some points: > 2. Presumably the user would still customize the /etc/inetd.conf > file or the /etc/xinetd.conf file. How about having the script that generates /etc/*inetd.conf also having a function to reverse this? I know that it's the users own fault, but that might also help moving existing configs to a new design. You could also detect whether a file or an entry is autogenerated (preferably with a checksum of some type). > 4. I think tcpd is inetd.conf specific, so I would assume update-inetd > should add it as appropriate. AFAIK xinetd has some libwrap calls built-in, however, the manpage references tcpd also and there seems to be a mechanism and some benefits in using it. > 5. Maximum-concurrent-connections, IIRC is a parameter that can > be specified in xinetd.conf. I thought that there is a per_source as well as a connections per second and lots of other stuff, but I don't remember a limit on the absolute number of connections. > 6. I have assumed that setting up xinetd.conf to listen only on > certain addresses, etc, is a system-admin function, and should not > be listed in above file. However it might lead to more secure stock setups when some services only bind to localhost by default. Also, I have the same service with different configurations (e.g. different TLS certificates) on the same IP. I wonder if it's that uncommon (especially since xinetd+stunnel a very nice way to get some programs to ssl), so it might be worth considering such setups. I might also ask for a way to specify some defaults. E.g. default address to bind to or the "flags=REUSE" for xinetd. Also, some generic way to add options which are normally not handled by this configuration could be nice (e.g. X-Xinetd-flags: RESUE in above example.) (Just my thoughts.) Cheers T.
Attachment:
pgpceqc4vlHnD.pgp
Description: PGP signature