On Do, 22.06.23 10:25, Chris Adams (linux@xxxxxxxxxxx) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> said:
> > I was hoping we would be make the dependency on setup optional.
> > It is a fairly heavyweight package (700+ kb) and with lots of
> > not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
> > csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
> > clutters /etc, which ideally would be empty, and also /etc/services is 700 kb.
>
> /etc/services and /etc/protocols are AFAIK mandatory if you want to have
> network services (either client or server). I don't think there's
> anything else providing that information.
getservbyname() always and getaddrinfo() under certain circumstances
(i.e. if 2nd argument actually uses a textual service name) use these
files.
But I think in the year 2023 programs actively using this should
probably be fixed not do so, and just use literal port numbers.
The service database in /etc/ is a really weird concept since it
suggests this mapping was configurable. But it really isn't, because
it's of course generally the *server* of an IP service that picks the
port number, not the *client*. Hence if a client configures the
mapping between service name and port at will this is generally
useless since it's unlikely going to match what servers bound its
sockets to.
hence, I think it would be wise to fix programs across the
distribution to just use port numbers literally, and avoid the service
database. it's probably what most admin folks assume anyway.
And for programs that cannot easily bit fixed to work like this, it
would make sense to provide a split out package
("socket-databases.rpm"?), and then require those consuming packages
to depend on that.
"tcpdump" can also uses these databases as well, but at least I
personally always found that very much confusing and hindering, since
the data in the database is sometimes a bit too historical to be
useful. For example it thinks port 5355 is "hostmon", even though it
almost certainly is llmnr if see in the wild... And what's even worse:
local client sockets on Linux get auto-assigned port numbers from the
range 32768-60999 by default (see
/proc/sys/net/ipv4/ip_local_port_range), but /etc/services assigns a
ton of names to various ports from that range. For all these cases the
service info is just complete garbage.
Side note: because the service db is such a broken concept the socket
activation feature in systemd explicitly never supported it btw. And
while people complain about various of our "political" choices like
that, noone so far has noticed or complained this omission... So I
have serious doubts anyone cares about the concept at all...
(If such a split off "socket-databases.rpm" would be created I'd like
to suggest moving the database to /usr/ somehwere at the same time,
and then create a symlink from /etc/services to it, including via
tmpfiles.d/, to at least push people away from assuming that this was
actually configurable config file, and not just a dump of some
outdated IANA data).
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
