Bug 171906

This would require changing glibc's implementation of getservbyname, which I
suspect is unlikely to happen. Bouncing there first.

This makes not much sense.  The /etc/services file should only ever contain the
officially assigned numbers.  I'm sure that we are not distributing a file with
all the recent additions but that's a different problem.

Adding local definitions in the file is pure madness since every single machine
would have to be modified.  Instead, for this the NIS/LDAP services should be used.

Typical usage is you install a daemon that talks on port XXX
You need to open the local firewall so clients can actually connect to this port.
So you just dump a descriptive name in /etc/services and add an iptables rule
that uses this

Clients OTOH don't need to do anything since the default rules will let them
connect to any outbound port

Why would you need NIS/LDAP to define a port on a single system ?

If you object to a whole /etc/services.d/ directory could we at least have and
/etc/services containing "official" Red Hat - blessed services names and a
/etc/services.local containing local names ?

I knew this bogus "what about one system" argument comes up.

You completely miss the purpose of this file.  It has once been imagined to
synchronize the use of named service ports accross multiple systems.   If this
isn't the case, i.e., it's only a local system, there is no point in using this
file.

And if distributed systems are used it only ever makes sense to either have an
officially assigned number or use the same number from multiple places using
services like NIS and LDAP.

There will be no addition to glibc for /etc/service.d nor /etc/service.local. 
Neither makes _any_ sense.  Period.

However 

- addition of local names is explicitely encouraged by the current file and all
its previous versions (they all end with # Local services)

- if this file is just for assigned names, where are you supposed to put private
name definitions ? And don't tell me because they're not "official" you have to
hardcode port numbers everywhere

- NIS and LDAP are way overkill for this, besides when you're in a DMZ the last
thing you want is all your servers depending of an external LDAP/NIS service

Your comments show you believe local definitions has no place in this particular
port table. Fine by me. I'm proposing to put them elsewere - you should be happy
about it. If you don't provide some place to put them they'll stay in
/etc/services like now with all the problems that causes.

Alternatively, if you insist that local names should not exist, should I file a
bug on the setup component every single time I encounter a service not
referenced in /etc/services ? I'm sure Bill Nottingham would be delighted to
learn this.

The file only contains official numbers.  If there is a file from IANA it should
be updated before a release.

And stop reopening this bug.

Allright

You don't want local services in the current file, you don't want to provide any
other place where to put them, you don't even want to know why people need this.

Since in the real world local services exist, they'll be put in the current file
like now. With triggers fighting for control of this file. And Red Hat support
cleaning up the mess.

Don't come crying later app writers and packagers don't respect your beautiful
guidelines. They can only work with what you give them - if it's inadequate,
it'll be abused

Ok, now that we've heard the opinion of the glibc people, that iptables should
depend on external NIS/LDAP to setup it's filtering rules, what is the next step ?

Create a library separate from glibc dedicated to reading a local service table
somewhere ?

Try to manage the current situation by having several packages poking at the
same file ?

Wait for firewalls to be silently disabled and have people change to a more
secure OS ?

Well, if you *reaaaaaaaaally* wanted to have something like services.d, you
could cook up a custom NSS module that would read it and set nsswitch to use
that. But that would be somewhat overkill.

Ok.

Then we're back to square one -> make /etc/services noreplace since we've shown
it's not likely there will be another place to put local services in the short
term, and if you put local services in /etc/services blindly replacing it on
upgrades may kill your firewall.

That, or adding a lot of smarts to iptables so an iptable initialisation failure
blocks network startup. Or maybe load the iptables rules that work and ignore
the others instead of failing completly like now.

/etc/services noreplace was always the quickest fix, it would have been nice to
make this workaround unecessary though

services has been noreplace since:

* Mon Sep 27 2004 Rik van Riel <riel> 2.5.34-2
- mark /etc/services config(noreplace) (#133683)

If you wanted a custom NSS module, there *is* nss_directories, available from
http://people.redhat.com/nalin/testing/. But that's rather experimental.

I'll close the two bugs then.

noreplace was whet I asked for in the first place, this RFE was just an attempt
to find a clean solution