Alexander Koch <[EMAIL PROTECTED]> wrote:
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.
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 <[EMAIL PROTECTED]> wrote:
would it be possible/practical to...make /etc/services a generated
file from a collection of files in say /etc/services.d with a
update-services script
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?).
On the up side, the update-services script could process the files in
/etc/services.d in order, and permit files later in the sort order to
override port specifications that appear earlier. A scheme similar to
what's used in /etc/inetd.conf for disabling services could be used in
the /etc/services.d files to cause the script to disable services listed
in the DEFAULT file or other files earlier in the sort order. (I could
provide a Perl script that implements this, if desired.)
Marco d'Itri <[EMAIL PROTECTED]> wrote:
Robert Sander <[EMAIL PROTECTED]> wrote:
Could this please be implemented in a simple manner already
suggested in this bug report?
No.
Is that "No, it can't be done simply" or "No, I reject this idea."
Could you elaborate?
-Tom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
