Page MenuHomeFreeBSD

inetd: Add examples from manual page and other sources
ClosedPublic

Authored by debdrup on Feb 23 2021, 9:36 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 15, 11:14 PM
Unknown Object (File)
Fri, Mar 15, 11:14 PM
Unknown Object (File)
Fri, Mar 15, 11:14 PM
Unknown Object (File)
Tue, Mar 12, 3:59 AM
Unknown Object (File)
Tue, Mar 12, 3:59 AM
Unknown Object (File)
Tue, Mar 12, 3:48 AM
Unknown Object (File)
Feb 16 2024, 6:09 AM
Unknown Object (File)
Feb 5 2024, 8:49 PM

Details

Summary

The manual page lists a bunch of examples, some of which already exist
in this file. Since it's both easier to remember when all examples are
listed in the same location, move examples so they get installed into
/etc/inetd.conf

This also means users won't have to copy-paste, but can simply
uncomment one or more services to use them.

As such, it also becomes necessary to remove the examples from the
manual page, so instead add a note explaining where the previous
examples as well as others may be found.
Cross-references, including to ports, have also been added where
applicable.

The rsync example has lived in the bug tracker for too long,
considering how useful it can situationally be, for example when
backup jobs on client devices are run through periodic(8) weekly.

The microsoft-ds entry is necessary for Windows 10 compatibility
(this can be confirmed with packet capturing, as it is not readily
documented at time of writing).

While here, remove two examples for which compatible daemons could not
be found in ports.

Submitted by: David Yeske <dyeske at gmail.com> (in part, prev ver)
PR: 122037

Test Plan

Igor and mandoc; both passed for lines modified

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 37354
Build 34243: arc lint + arc unit

Event Timeline

Just being curious, what's the benefit of running rsyncd through inetd instead of using its standalone daemon?

Just being curious, what's the benefit of running rsyncd through inetd instead of using its standalone daemon?

The main advantage of inetd is that it starts a daemon only when a request comes in.

For rsyncd, smbd, prometheus_sysctl_exporter, et al., if the client machines have a weekly rsync job, or if prometheus only probes every 5 minutes, or only the occational connection via SMB is made - it makes more sense to only start them when they're needed.

Naturally, if you're constantly doing persistent samba sharing, 10-second to 2 minute probes with prometheus, or constant rsync backup jobs over the net, running the daemon via a rc script makes more sense.

The main advantage of inetd is that it starts a daemon only when a request comes in.

For rsyncd, smbd, prometheus_sysctl_exporter, et al., if the client machines have a weekly rsync job, or if prometheus only probes every 5 minutes, or only the occational connection via SMB is made - it makes more sense to only start them when they're needed.

This sounds fair to me. I'm fine with adding them.

usr.sbin/inetd/inetd.conf
124

I'm not sure if this is needed to add this, but we don't have if_wg(4) manpage.

debdrup retitled this revision from inetd.conf: Add entries for Samba sharing and rsyncd to inetd: Add examples from manual page and other sources.Feb 24 2021, 8:21 PM
debdrup marked an inline comment as done.

Rework review to address outstanding issues with examples

Also fix reference to wg(4) which was mistakenly referred to by if_wg(4)

debdrup edited the test plan for this revision. (Show Details)
debdrup edited the summary of this revision. (Show Details)

Rework review to address outstanding issues with examples

Also fix reference to wg(4) which was mistakenly referred to by if_wg(4)

I somehow feel the better fix is creating if_wg MLINK.

brueffer added inline comments.
usr.sbin/inetd/inetd.8
794

I think implicitly referring to the previous state of the manpage doesn't add much value; how about the following:

Examples for a variety of services are available in
.Pa /etc/inetd.conf .

975
yuripv added inline comments.
usr.sbin/inetd/inetd.8
807

"samba sharing" does not make much sense, may be "SMB sharing using Samba"? Or rather "Samba NETBIOS name server".

820

it's a software package name here, so Samba.

824

trailing comma, replace with period?

974

not needed in SEE ALSO

usr.sbin/inetd/inetd.conf
110

Samba services?

113

Samba?

debdrup marked 8 inline comments as done.

Address feeeback by @yuripv and @brueffer

Since inetd.conf already explains the link between nmbd and NetBIOS,
there's no reason to elucidate it in the manual page.

I somehow feel the better fix is creating if_wg MLINK.

if_wg(4) doesn't exist and all the documentation I could find refers to wg(4) for VTIs.

Why if_ is not prepended when it's a VTI, I don't know, but that's outside the scope of this review.

I somehow feel the better fix is creating if_wg MLINK.

if_wg(4) doesn't exist and all the documentation I could find refers to wg(4) for VTIs.

Why if_ is not prepended when it's a VTI, I don't know, but that's outside the scope of this review.

I mean, we should do this: https://cgit.freebsd.org/src/commit/?id=655fa04406010e56822802e12bf52f42e333988b to fix in a better way.

Also, what stands for VTI? virtual interface? It's non-trivial to me and maybe we can have its full name?

I mean, we should do this: https://cgit.freebsd.org/src/commit/?id=655fa04406010e56822802e12bf52f42e333988b to fix in a better way.

Also, what stands for VTI? virtual interface? It's non-trivial to me and maybe we can have its full name?

Well, now it exists. :)
I'm still not sure about referring to it by something it isn't called everywhere else?

VTI stands for virtual tunnel interface.
It's a generic term for everything from if_gre(4), if_ipsec(4), wg(4) and even tun(4) and tap(4)

Speaking of those, they're now both using the tuntap device, but they don't have a manual page - that's something I should look into writing. It's also out-of-scope for here. ;)

Anywho, is this commit ready to be pushed? If so, can I get it accepted, or does anyone need more time?

This revision is now accepted and ready to land.Feb 26 2021, 1:39 PM