I wonder if it is worth trying to have a /etc/services.local
that automatically gets appended to *any* update of the
/etc/services file the user agrees to.

Because I have lots of local services for self-made scripts
run from inetd and stuff that I have to be too *** careful
about when a netbase update is coming (these times it is
easier to miss such things if all you do is apt-get upgrade).

Let's put it that way: If the file /etc/services.local
exists, the admin of that box usually knows what he is
doing, isn't he? So ... do I miss something?

Thanks for consideration.

Alexander

hmm..  I rather like this idea..  would it be possible/practical to do
something like what is done with /etc/conf.modules

ie. make /etc/services a generated file from a collection of files in
say /etc/services.d with a update-services script

I would love to see something like this I have local service definitions
on almost all my boxes and have to manually update after each upgrade
that includes netbase.  This would be a nice solution to the problem.

hi,

sadly, I see this first bugrep is way old, yet bug's still(*) there, but
shouldn't be too hard to fix.
While it may be minor, indeed it's worse, it may break services, both
locally defined and standard - eg if you installed Epson's pips-*, and remove
the pips-* -installed service, lpd/printing may hang.
Of course anything else relying on such services stop working.  Too bad.
Adding just

[ -f /etc/services.local ] && cat /etc/services.local >> /etc/services

as suggested to the postinst, and due user warning to move local services
to such /etc/services.local, or better, a bit more elaborated patch,
which allows for no changes in config:

nl=`wc -l < /etc/services`
ls=`grep -ni '^#[ ]*Local[ ]*services' /etc/services|cut -d: -f1`
tail -$[nl-$ls] /etc/services >> /etc/services.dpkg-new

doesn't seem too complex or at risk of subverting anything.

(*) on last apt-get update+upgrade, a few minutes ago, this bug broke a
Sarge install, once again.

Hi!

I would like to add the a /etc/services.local file are a /etc/services.d
directory would be very very useful.

Could this please be implemented in a simple manner already suggested in
this bug report?

Greetings

No.

Alexander Koch <efraim@really.argh.org> wrote:

Well you wouldn't want to literally append to /etc/services, otherwise
you end up with the same problem - a local copy of /etc/services that
differs from the distribution version.

If the current distribution /etc/services is stored in a different file
(/etc/services.default /etc/services.d/DEFAULT), then /etc/services
could become a disposable, generated file.


Ron <ron@microtronics.com.au> wrote:

The collection approach might be overkill for this, given that each file
will likely contain only one or two lines, but it obviously makes it
easier for automated installers to manage.

I think the trick to the "update-services" script is figuring out what
event should trigger running it. Most other places where such a
collection is used, the utilizing program directly works with the
individual files or you have a single consumer of the information and
can regenerate the aggregated file when that program starts up. (I
believe /etc/services is queried by multiple programs.)

In this case, you have to depend on installer scripts and the user to
remember to run update-services after edits. You could add yet another
cron job to regenerate the file whenever it detected that the
modification date on /etc/services.d/* was newer than /etc/services, but
that could lead to some user confusion if the user expects the change to
be picked up immediately, yet the cron job only runs once every 5
minutes (hour? day?).

Is that "No, it can't be done simply" or "No, I reject this idea."
Could you elaborate?

  -Tom

Both. Too much complexity for minimal gains.

Hi.

Is this considered as a wontfix-bug in the meantime?

I'd be very interested in a solution,... even the services.d/ sounds
not so unreasonable to me.
It would allow packages to ship their own files which would give us
even some sort of stupid conflict resolution if more packages use the
same port-number for different protocols.
(Users could use the alternatives mechanism e.g.)

I also think that a services.d/ solution wouldn't be that overkill,..
I'm running a very large storage element cluster, part of the
worldwide LHC Computing Grid, and we have quite a few portnumbers from
different programs or even big portranges, where it would be nice to
see the right names in the tools using /etc/services.


Best wishes,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

It will never happen, ever.

Then,... can we set wontfix?


Chris.

/etc/service.d -> wontfix ? Or is somebody still thinking about it ?

I think it would be really handy, but I just need to know if I should write
my own scripts or wait for a package update ...

Kindest regards,

Peter.

I do not expect that this will happen, ever.

Any particular reason?

We did this a couple of months ago as an NSS module, which we're
planning on submitting upstream just as soon as we have some time.

Alternately, if there is still interest in merging in the contents
of /etc/services.local or similar, we've had a tool for that which we've
used on a variety of platforms since before this bug existed.
Unfortunately, it depends on perl, which would be an unacceptable
dependency for netbase.  However, if anyone is interested in using it
locally, they are welcome to do so; see

http://source.fac.cs.cmu.edu/cvsweb/dist/commonx/usr/adm/fac/bin/newservices

Low benefits, high cost and complexity.
Configuration files are editable for a reason.

-------- Forwarded Message --------
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Marco d'Itri <md@Linux.IT>
Cc: jhutz@cmu.edu
Subject: Re: Bug#46049: local services
Date: Tue, 11 Oct 2011 14:08:55 -0400
full of files instead of a single file is not that high, and the
benefits are significant, which is why this approach has been deployed
throughout the system.  In particular, it eliminates two problems, which
taken together result in an intolerable situation:

1) Users wishing to add or update entries in /etc/services are forced
   to take manual action on every update, to merge local changes in
   with the new packaged database.  UCF would make this a little less
   painful, but as you correctly point out, it can't be used here
   unless/until it is promoted.  And, it doesn't really resolve the
   problem, because the user _still_ has to react to every update.

2) Maintainers needing to add or update entries in /etc/services are
   forced to submit a bug and wait for an updated netbase.  I haven't
   paid attention to how promptly this happens, so I'm not suggesting
   that this takes too long.  However, you're pretty much forced to
   choose between infrequent updates, which creates problems for new
   packages, or frequent updates, which exacerbates (1).  Additionally,
   this puts you in the critical path for every new network-based
   service, which creates both a bottleneck and unnecessary work for
   you.


I can understand not wanting to introduce much additional complexity
into netbase which, after all, is both fairly simple and an important
package.  Personally, my preferred solution is the introduction of
libnss-dir:

Description: nss module to use directories (e.g /etc/hosts.d)
  This Name Service Switch (NSS) module works much like the 'files'
  service, but allows the local database to be constructed from an
  entire directory of files (e.g. /etc/hosts.d) instead of only a
  single file (/etc/hosts).
  .
  This module fully supports the ethers, hosts, networks, protocols,
  rpc, and services databases.  It also implements passwd, group, and
  shadow, but use of these is not recommended except under unusual
  circumstances, because it may not interact well with tools such as
  adduser(8).


However, I don't think the complexity of merging e.g. /etc/services.d is
too high.  Particularly, while inelegant, 'cat' is actually sufficient
as a merge tool for this case.

Sehr geehrter Kunde,

Ihre Bank hat die Lastschrift zurück gebucht. Sie haben eine ungedeckte Forderung bei unseren Mandanten Directpay GmbH.

Aufgrund des bestehenden Zahlungsverzug sind Sie verpflichtet außerdem, die durch unsere Inanspruchnahme entstandenen Gebühren von 20,17 Euro zu tragen. Wir erwarten die Zahlung bis zum 24.03.2015 auf unser Bankkonto. In Vollmacht unseren Mandanten fordern wir Sie auf, die noch offene Forderung sofort zu bezahlen.

Es erfolgt keine weitere Mahnung. Nach Ablauf der festgelegten Frist wird die Akte dem Gericht und der Schufa übergeben. Die vollständige Kostenaufstellung, der Sie alle Buchungen entnehmen können, ist beigefügt. Für Rückfragen oder Anregungen erwarten wir eine Kontaktaufnahme innerhalb des gleichen Zeitraums.

Mit freundlichen Grüßen

Inkasso Slakany Oskar