Re: Bug#500176: This bug is still around and release-critical - Debian

This is a discussion on Re: Bug#500176: This bug is still around and release-critical - Debian ; severity 500176 important thanks FWIW this problem is found in many other cases: see lighttpd with apache2 installed, or caudium or any other http daemon, and none of them has a bug about it, it's unfair to mark it as ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Re: Bug#500176: This bug is still around and release-critical

  1. Re: Bug#500176: This bug is still around and release-critical

    severity 500176 important
    thanks

    FWIW this problem is found in many other cases: see lighttpd with
    apache2 installed, or caudium or any other http daemon, and none of them
    has a bug about it, it's unfair to mark it as RC.

    On Wed, Oct 01, 2008 at 09:47:38AM +0000, martin f krafft wrote:
    > reopen 500176
    > severity 500176 serious
    > thanks
    >
    > This bug is actually release-critical because installation leaves
    > the dpkg database in an unusable state. Please either conflict with
    > other DNS servers, do not start it by default, bind it to
    > 127.0.0.42, fail gracefully (which would not be ok, I think), or do
    > something else, but don't close bug reports about messages like
    >
    > Errors were encountered while processing:
    > unbound
    > E: Sub-process /usr/bin/dpkg returned an error code (1)



    I believe the problem here is somehow very generic, and that using a
    virtual package like proposed in the bug report (#500176) doesn't scale
    well. Especially for dns daemons. Packaging two of them myself (nsd3
    that is an authoritative server only, and pdnsd that is a caching daemon
    only) I can tell the virtual package solution would be a mess: I _want_
    to be able to use nsd3 _and_ pdnsd on the same machine (I actually do
    since the former binds to the external IPs only and pdnsd to 127.0.0.1)
    but by default nsd3 listens on 0.0.0.0 and you can't apt-get install
    pdnsd if you haven't configured nsd3 properly first. And you cannot make
    both conflict, both should work fine.

    Also I don't like setting a default file for every single daemon out
    there for the first install purpose only.


    Anyways I think there is a more general solution to find and here are a
    path. The fact that Debian starts every single service on first install
    is something that we strive for, but causes some grief for sysadmins
    that don't wish to open an unprotected service before they configured
    it. It also generates the issue we're disussing.

    Though, we could probably do better: a bit like solaris does, we could
    have some kind of service handler that wraps every single service, and
    if the start action fails, it marks the service as "broken" and refuse
    it to start, prints whatever warning you want to, but doesn't prevent
    the package manager to do its job.

    People could also probably configure it so that when first installed a
    service would be in the "broken" or "unconfigured" or "disabled" state,
    so that it's not started by default, which would please somehow
    everyone.

    If you do so, the problems that criple multiple installs of different
    $service servers that would like to bind on the same port disappears. It
    would also help a lot for chroots and things like that.

    Technically it would mean that we need a simple tool * la svc (I think
    it's how the solaris counterpart is known as, and fwiw I don't know it
    well, I just saw _this_ functionnality, and I believe we want it) in
    Base, that would provide a /lib/init/service-functions.sh that every
    single /etc/init.d script would have to include (well maybe not
    bootmisc.sh or friends of course, but you grok the general idea of
    course). Coming with it a simple database of the disabled/broken/...
    services. Then it would work like this:
    * If you /etc/init.d/$service start/reload/restart a service that is
    disabled or broken, an error message would appear saying that there
    was some problem with the service and that you must run "debian-svc
    enable $SERVICE" to enable it again.

    * stop action would always be enabled.

    * If the start action fails, then the service would automatically be
    put in the broken state. The maintainer could help in that regard
    using:
    start-stop-daemon .... || debian-svc broken "$some_reason"
    or the sourcing of /lib/init/service-functions.sh could also trap
    errors and do an automatic
    'debian-svc broken ""'

    As a side effect, most of the "ENABLED=true|false|yes|no|..." tricks in
    /etc/default/$service could be dealt with from the postinst that when
    it's a first install would force the service to be disabled by default
    in a more generic way.

    I don't believe such a service manager is hard to write, though it
    requires some bit of migration of the maintainer scripts, which could be
    a worthy squeeze release goal. What do people think ?

    --
    ·O· Pierre Habouzit
    ··O madcoder@debian.org
    OOO http://www.madism.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjohkMACgkQvGr7W6HudhzW6gCfYvWO6Wj6Iu dpNWESekjQ4Zmi
    UssAn3oUuiCr0k0UT0noJP8SiUEvPPi+
    =Mg+L
    -----END PGP SIGNATURE-----


  2. Re: Bug#500176: This bug is still around and release-critical

    also sprach Pierre Habouzit [2008.10.05.1117 +0200]:
    > FWIW this problem is found in many other cases: see lighttpd with
    > apache2 installed, or caudium or any other http daemon, and none
    > of them has a bug about it, it's unfair to mark it as RC.


    Uh, don't you think that marking it down to important for this
    reason is not the solution? It's not "unfair" to file an RC bug for
    something I consider an RC problem: an unusable (albeit far from
    corrupted) dpkg database!

    > I believe the problem here is somehow very generic, and that using a
    > virtual package like proposed in the bug report (#500176) doesn't scale
    > well.
    > [...]
    > Anyways I think there is a more general solution to find and here
    > are a path. The fact that Debian starts every single service on
    > first install is something that we strive for, but causes some
    > grief for sysadmins that don't wish to open an unprotected service
    > before they configured it. It also generates the issue we're
    > disussing.
    >
    > Though, we could probably do better: a bit like solaris does, we
    > could have some kind of service handler that wraps every single
    > service, and if the start action fails, it marks the service as
    > "broken" and refuse it to start, prints whatever warning you want
    > to, but doesn't prevent the package manager to do its job.


    Agreed, that would be nice. While this is something to consider for
    squeeze release goals, how do we solve the problem for lenny?

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "the husbands of very beautiful women
    belong to the criminal classes."
    -- oscar wilde

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjpwsIACgkQIgvIgzMMSnW3yQCePEggz4K+Ec R7lsfOC8kbRjvQ
    xV0AoONAI6Zr/StSai1XOG0OThWKoLXm
    =BnyP
    -----END PGP SIGNATURE-----


  3. Re: Bug#500176: This bug is still around and release-critical

    On Mon, Oct 06, 2008 at 07:48:18AM +0000, martin f krafft wrote:
    > also sprach Pierre Habouzit [2008.10.05.1117 +0200]:
    > > FWIW this problem is found in many other cases: see lighttpd with
    > > apache2 installed, or caudium or any other http daemon, and none
    > > of them has a bug about it, it's unfair to mark it as RC.

    >
    > Uh, don't you think that marking it down to important for this
    > reason is not the solution? It's not "unfair" to file an RC bug for
    > something I consider an RC problem: an unusable (albeit far from
    > corrupted) dpkg database!


    The dpkg database is _not_ corrupted in that case, you can do multiple
    things, and if you believe it's not adequate then you can report an RC
    bug on linux too that does this on purpose if you e.g. uninstal your
    currently running kernel.


    > > I believe the problem here is somehow very generic, and that using a
    > > virtual package like proposed in the bug report (#500176) doesn't scale
    > > well.
    > > [...]
    > > Anyways I think there is a more general solution to find and here
    > > are a path. The fact that Debian starts every single service on
    > > first install is something that we strive for, but causes some
    > > grief for sysadmins that don't wish to open an unprotected service
    > > before they configured it. It also generates the issue we're
    > > disussing.
    > >
    > > Though, we could probably do better: a bit like solaris does, we
    > > could have some kind of service handler that wraps every single
    > > service, and if the start action fails, it marks the service as
    > > "broken" and refuse it to start, prints whatever warning you want
    > > to, but doesn't prevent the package manager to do its job.

    >
    > Agreed, that would be nice. While this is something to consider for
    > squeeze release goals, how do we solve the problem for lenny?


    I see no proper fix, except using an /etc/default file, which is ugly.


    --
    ·O· Pierre Habouzit
    ··O madcoder@debian.org
    OOO http://www.madism.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjqFqEACgkQvGr7W6HudhxrPQCeMiO2pCf38H y7yDcY8zQvSRuC
    7qMAn1pm+1PgOm/T0gedjxyCk6DNl7pC
    =9N1F
    -----END PGP SIGNATURE-----


  4. Re: Bug#500176: This bug is still around and release-critical

    On 2008-10-05, Pierre Habouzit wrote:
    > FWIW this problem is found in many other cases: see lighttpd with
    > apache2 installed, or caudium or any other http daemon, and none of them
    > has a bug about it, it's unfair to mark it as RC.


    also note that this bug isn't symmetric with bind9, which
    opportunistically attempts to bind every ip address on the system.
    (in fact, it will periodically re-scan the interfaces list and attempt
    to bind new ip address on the system; see the 'interface-interval'
    setting.) if no addresses can be bound, named will still start.

    i just installed bind9 on a test system running unbound and found that
    the bind9 package installed rc?.d symlinks at the S15 level, which
    causes it to start sooner than unbound at S85. after a reboot, unbound
    will fail to start since bind9 has bound the ip addresses unbound uses.
    (by default, unbound only tries to bind 127.0.0.1 and ::1). so
    installation in the order (unbound, bind9) will succeed and both daemons
    will start, but at boot the startup order (bind9, unbound) will fail.

    > I believe the problem here is somehow very generic, and that using a
    > virtual package like proposed in the bug report (#500176) doesn't scale
    > well. Especially for dns daemons. Packaging two of them myself (nsd3
    > that is an authoritative server only, and pdnsd that is a caching daemon
    > only) I can tell the virtual package solution would be a mess: I _want_
    > to be able to use nsd3 _and_ pdnsd on the same machine (I actually do
    > since the former binds to the external IPs only and pdnsd to 127.0.0.1)
    > but by default nsd3 listens on 0.0.0.0 and you can't apt-get install
    > pdnsd if you haven't configured nsd3 properly first. And you cannot make
    > both conflict, both should work fine.


    yes, virtual packages are a nonstarter because of all the strange ways
    dns can be combined on the same machine (see, e.g., the dnsproxy
    package).

    --
    Robert Edmonds
    edmonds@debian.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Bug#500176: This bug is still around and release-critical

    Hi,

    On Mon, 06 Oct 2008 15:46:11 +0200
    Pierre Habouzit wrote:
    > > Agreed, that would be nice. While this is something to consider for
    > > squeeze release goals, how do we solve the problem for lenny?

    >
    > I see no proper fix, except using an /etc/default file, which is ugly.


    Using /etc/default/unbound is reasonable, I think. Some of daemon packages
    (e.g. rsync) are not started by default because it is set in its /etc/default
    file.

    # Some Unbound users ask me "Will lenny include unbound package?" at
    Conference, Japan. So, if you allow me to fix this by using /etc/default,
    I'll try it (but I think it is better that you'll do it because I'm not
    a good programmer ;-).

    --
    Regards,

    Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
    http://wiki.debian.org/HidekiYamane


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Bug#500176: This bug is still around and release-critical

    On Mon, Oct 06, 2008 at 05:13:32PM +0000, Robert Edmonds wrote:
    > On 2008-10-05, Pierre Habouzit wrote:
    > > FWIW this problem is found in many other cases: see lighttpd with
    > > apache2 installed, or caudium or any other http daemon, and none of them
    > > has a bug about it, it's unfair to mark it as RC.


    FWIW I've upgraded a machine to replace pdnsd with unbound, it hit that
    bug of course.

    I've:

    1) edited /etc/unbound/unbound.conf.
    2) stopped pdnsd,
    3) ran apt-get -f install , which "repaired" the dpkg database.
    4) dpkg --purge pdnsd

    and done.

    I don't think this is too hard to ask from someone that is installing
    multiple DNS softwares on the same machine. A bit more user friendly
    steps could help, but well...
    --
    ·O· Pierre Habouzit
    ··O madcoder@debian.org
    OOO http://www.madism.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjsdS4ACgkQvGr7W6HudhxPYwCgqW49esz9xj n6oz4p85i27hAH
    M/YAn3aEy23NgksToMdSkddBjEdW95T9
    =IsGu
    -----END PGP SIGNATURE-----


  7. Re: Bug#500176: This bug is still around and release-critical

    also sprach Pierre Habouzit [2008.10.08.1054 +0200]:
    > FWIW I've upgraded a machine to replace pdnsd with unbound, it hit that
    > bug of course.

    [...]
    > I don't think this is too hard to ask from someone that is installing
    > multiple DNS softwares on the same machine. A bit more user friendly
    > steps could help, but well...


    I agree that #500176 needs a more generic solution, but I can't
    think of any right now. It would be good to have this as a release
    goal. One thing I was thinking of was port-xyz virtual packages, but
    that already doesn't work with DNS...

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "in the stage of grand illusion
    you walked into my life
    out of my dreams."
    -- david bowie

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjtrZQACgkQIgvIgzMMSnUZNQCfUWMTkuhI5l sgp3AAiZvLwnWV
    Du4AnjP0qchI/nLfyIPKRF6/ItBxpARF
    =4rtX
    -----END PGP SIGNATURE-----


  8. Re: Bug#500176: This bug is still around and release-critical

    On Thu, Oct 09, 2008 at 09:07:00AM +0200, martin f krafft wrote:
    > also sprach Pierre Habouzit [2008.10.08.1054 +0200]:
    > > FWIW I've upgraded a machine to replace pdnsd with unbound, it hit that
    > > bug of course.

    > [...]
    > > I don't think this is too hard to ask from someone that is installing
    > > multiple DNS softwares on the same machine. A bit more user friendly
    > > steps could help, but well...

    >
    > I agree that #500176 needs a more generic solution, but I can't
    > think of any right now. It would be good to have this as a release
    > goal. One thing I was thinking of was port-xyz virtual packages, but
    > that already doesn't work with DNS...


    Maybe
    http://thread.gmane.org/gmane.linux....92/focus=88198

    Regards, Gerrit.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Bug#500176: This bug is still around and release-critical

    On Thu, Oct 09, 2008 at 09:07:00AM +0200, martin f krafft wrote:
    > also sprach Pierre Habouzit [2008.10.08.1054 +0200]:
    > > FWIW I've upgraded a machine to replace pdnsd with unbound, it hit that
    > > bug of course.

    > [...]
    > > I don't think this is too hard to ask from someone that is installing
    > > multiple DNS softwares on the same machine. A bit more user friendly
    > > steps could help, but well...

    >
    > I agree that #500176 needs a more generic solution, but I can't
    > think of any right now. It would be good to have this as a release
    > goal. One thing I was thinking of was port-xyz virtual packages, but
    > that already doesn't work with DNS...


    Another problem that is looking for a solution is programs such as apache
    or dnsmasq which binaries may be used by other software (gnome-user-share,
    virt-manager...) but shouldn't be running daemons in this case.
    It is especially a PITA when installing and using the daemon screws up your
    setup (happened to me with dnsmasq)

    Mike


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Bug#500176: This bug is still around and release-critical

    also sprach Mike Hommey [2008.10.09.1024 +0200]:
    > Another problem that is looking for a solution is programs such as apache
    > or dnsmasq which binaries may be used by other software (gnome-user-share,
    > virt-manager...) but shouldn't be running daemons in this case.
    > It is especially a PITA when installing and using the daemon screws up your
    > setup (happened to me with dnsmasq)


    I don't think we should cater for broken software, where broken here
    refers to the pair of (other software using *binaries*, that
    software not factoring functionality into libraries).

    --
    .''`. martin f. krafft
    : :' : proud Debian developer, author, administrator, and user
    `. `'` http://people.debian.org/~madduck - http://debiansystem.info
    `- Debian - when you have better things to do than fixing systems

    "ist gott eine erfindung des teufels?"
    - friedrich nietzsche

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjuVKAACgkQIgvIgzMMSnV6LwCg0Uw5X6BPaI k/lhAa7TwUxF4P
    GdIAoOqvv6l9qMsb5V9aOl9V8H8wHE88
    =iqSu
    -----END PGP SIGNATURE-----


  11. Re: Bug#500176: This bug is still around and release-critical

    Hello Pierre,

    Pierre Habouzit wrote:
    > I believe the problem here is somehow very generic, and that using a
    > virtual package like proposed in the bug report (#500176) doesn't scale
    > well. Especially for dns daemons. Packaging two of them myself (nsd3
    > that is an authoritative server only, and pdnsd that is a caching daemon
    > only) I can tell the virtual package solution would be a mess: I _want_
    > to be able to use nsd3 _and_ pdnsd on the same machine (I actually do
    > since the former binds to the external IPs only and pdnsd to 127.0.0.1)


    > Anyways I think there is a more general solution to find and here are a
    > path. The fact that Debian starts every single service on first install
    > is something that we strive for, but causes some grief for sysadmins
    > that don't wish to open an unprotected service before they configured
    > it. It also generates the issue we're disussing.


    If the idea of update-rc.d disable|reenable[1] gets implemented, it would
    be enough to disable a service after first installation. update-rc.d
    could do that.

    [1] http://lists.debian.org/debian-devel.../msg00623.html

    Bye, Jörg.
    --
    Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
    kopfüber, in der Schwerelosigkeit und unter Wasser schreiben kann.
    Die Russen benutzten einfach einen Bleistift …


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread