[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: netbase depends: inetd and xinetd as "network-daemon"



Chris Fearnley writes:
> >>Completely unnecessary since we have Replaces:.  netbase needs to
> >>support xinetd better and as I understand it the only problem is
> >>/etc/init.d/netbase.  Peter, any suggestions on how that can be
> >>improved?
> >plz exuse me, but i didn't quiet understand, how "Replaces" going
> >to help? do you want xinetd to replace netbase? or vice versa?
> 
> I'm sorry, my logic was leaping this morning :)  I meant that I don't
> see why netbase needs to be split into two pieces.  The only reason I
> can image for splitting is if you need to replace files from one
> package by another (hence my leap of logic).  I think the best solution
> is for an improved /etc/init.d/netbase perhaps in conjunction with
> update-alternatives??  Or maybe splitting /etc/init.d/netbase into two
> files one of which xinetd would Replaces:??  I'd like to hear what
> Peter thinks.

I'm sorry for answering so late. I'm quite busy these days (and it
won't get better the next two months).

There are at least two problems to fix:
(my preferred solutions are marked with a + character)

1. avoid that more than one inetd runs at the same time
   - which one should have priority
     - let the user choose
         - save choice in /etc/default and make sure
           that both xinetd and netbase use this file
           (the daemon should only be started if it had
           been selected)
         - change the own /etc/init.d/... file to stop
           the other (x)inetd
     - assign a default priority to xinetd and inetd
         - use alternatives mechanism
         - use divert mechanism
     + don't enable xinetd by default

2. find a solution for the update-inetd problem(s)
   - updating inetd.conf
     - change update-inetd so it will change inetd.conf
       and a xinetd.conf(?) file if available
     - change update-inetd to call the inetd.conf to
       xinetd.conf convert program and replace an
       existing /etc/xinetd.conf file
     + change update-inetd to call the inetd.conf to
       xinetd.conf conversion program and save the converted
       file to a new name (for example /etc/xinetd.conf.converted)
   - restart inetd
     - change update update-inetd to detect xinetd/inetd and
       to restart the daemon that is currently running
     - rename xinetd to inetd (alternatives/divert) and let
       update-inetd restart inetd
     + change both to use /var/run/inetd.pid and update-inetd
       will use this file to restart inetd (not necessary if
       the converted xinetd.conf file isn't used by default)

As you can see my preferred solution is to not enable xinetd by
default. And I don't prefer this solution because it means less
work for me :-). There are other reasons for it. I think that our
our networking programs should be compatible to the BSD networking.
Sysadmins changing from a different Unix version to Debian should
find an environment that they already know. That means inetd should
also be the default when a user installs xinetd too. A lot of users
think  "Hmm.. whats that for a program? It doesn't matter, I'll
install it too. It won't hurt".

Another problem is that update-inetd can't add entries to an
existing xinetd.conf file. That means that xinetd always has
to use the convert program to create an xinetd.conf file from
the inetd.conf file to get the new entries. Using this conversion
program would overwrite the existing xinetd.conf file by default.
This would destroy all changes that a user made to xinetd.conf.
A xinetd where the user can't change the config file doesn't
make much sense. It's better to save the converted inetd.conf
file to a different file and let the sysadmin make the changes
by hand (he can also use the converted inetd.conf file).

Disabling xinetd by default and let the sysadmin make the changes
to enable xinetd BY HAND is IMHO the best solution. The sysadmin
would only have to change /etc/init.d/netbase to disable inetd
(or a file in /etc/default) and /etc/init.d/xinetd to enable
xinetd (this could also be done automagically by checking whether
an inetd is already running or not). It might be a good idea
to let /etc/init.d/xinetd do this. Additional options like
"activate" and "deactivate" could enable/disable xinetd.
If the xinetd.conf file needs to be updated the sysadmin
can decide if he wants to use the converted inetd.conf which
update-inetd has created (by calling the conversion program
from xinetd) or if he wants to add the entries by hand.

This solution would minimize the installation and update problems,
it would minimize the confusion if the sysadmin finds a completely
different inetd version and would only require a small changes
from the sysadmin (he would do the change because he really
wants xinetd and not because xinetd has been installed).


Thanks,

Peter

-- 
 Peter Tobias                                EMail:
 Fachhochschule Ostfriesland                 tobias@et-inf.fho-emden.de
 Fachbereich Elektrotechnik und Informatik   tobias@debian.org
 Constantiaplatz 4, 26723 Emden, Germany     tobias@linux.de

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: