[regression] cups-daemon hard-depends on avahi-daemon

[MMlosh]

cups-daemon depends on avahi-daemon

This is probably the worst workaround possible for bug 1178172
Which is a combination of two separate issues
 o "cups requires avahi-daemon to be started before cups"
 o "cups's init script won't attempt to start cups if avahi-daemon is not installed / running"

There was no such issue on ubuntu 13.04 Precise or before.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Schlomo Schapiro (sschapiro)]

3 months and nothing happens? Please fix the init script of cups. Some people don't want to be forced to run avahi!

[Till Kamppeter (till-kamppeter)]

Is there no possibility in Upstart to get the following scenario:

- If avahi-daemon is installed always start CUPS after starting avahi-daemon )or do not start CUPS when avahidaemon is not yet started).
- If avahi-daemon is not installed and only then, start CUPS with avahi-daemon not running.

So CUPS should start independent whether avahidaemon is installed or not, but if avahidaemon is installed, CUPS has to be started after avahi-daemon.

Or should we let avahi-daemon restart CUPS when it is started while CUPS is already running, so that we get a CUPS session using avahi-daemon?

[Till Kamppeter (till-kamppeter)]

I have now done modifications on the CUPS daemon (Trusty, cups 1.7.1-5ubuntu3) so that it

- does not require avahi-daemon be started before cupsd. If avahi-daemon is started later, cupsd picks it up anyway and so starts Bonjour-broadcasting its shared printers as soon as avahi-daemon is up and running.
- is robust against stopping and restarting avahi-daemon. Bonjour broadcasts of shared printers stop when avahi-daemon stops and start gain when avahi-daemon starts again.

This eliminates the start order dependency between cupd and avahi-daemon (cups-browsed has similar functionality, so there are no startup order dependencies between the three).

In addition it improves server robustness and usability, as restarting avahi-daemon (after a configuration change for example) does not require restarting cups or cups-browsed any more.

So I want everyone with this problem to do a test:

First, if you are not running Trusty (14.04 LTS under development), install this system on a USB stick or a spare machine/partition. Boot the system, set up printers and share them. Share also printers on other machines so that they get visible in your test system. Check whether the printer sharing in both directions works.

Now edit the files /etc/init/cups.conf and /etc/init/cups-browsed.conf removing the line

          and started avahi-daemon

After that reboot your test system and check whether the printer sharing in both directions works.

Uninstall the avahi-daemon package and see whether after reboot cupsd and cups-browsed are running. You will not have printer sharing but should be able to print locally. Install avahi-daemon again, printer sharing in both directions should kick in immediately.

Does this all work?

[MMlosh (mmlosh)]

That's awesome, thanks for figuring out how to make it work cleanly for everyone.

There is a problem with the testing request, though.
It's highly likely, that subscribers of this thread want to keep avahi far away from their systems
Therefore they probably won't have the cups+avahi setup required for testing.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.7.1-5ubuntu8

---------------
cups (1.7.1-5ubuntu8) trusty; urgency=low

  * Removed har dependency of cups-daemon on avahi-daemon, demoted Depends: yo
    Recommends: and removed "on started avahi-daemon" from the "start on ..."
    rule in /etc/init/cups.conf (LP: #1242185, LP: #1178172).
 -- Till Kamppeter <email address hidden> Fri, 7 Mar 2014 17:45:01 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups-filters - 1.0.47-0ubuntu1

---------------
cups-filters (1.0.47-0ubuntu1) trusty; urgency=medium

  * New upstream release 1.0.47
     - pdftoopvp: SECURITY FIX for CVE-2013-6474, CVE-2013-6475,
       and CVE-2013-6476: Introduction of gmallocn and gmallocn3
       to protect against arbitrary code execution with the
       privileges of the "lp" user via malicious PDF files. Also
       restrict the directory from where OPVP drivers can get
       loaded.
     - urftopdf: SECURITY FIX for CVE-2013-6473: Two heap-based
       buffer overflow flaws in urftopdf. If a malicious URF file
       were processed it could lead to arbitrary code execution
       with the privileges of the "lp" user.
     - pdftopdf: Fixed typo in initialization which sets the default
       value page border to an undefined value. Thanks to Helge
       Blischke for the patch.
     - cups-browsed: Check for changes of the URI of a queue which
       we have created and correct the URI if needed, especially if
       a queue was not removed on shutdown of cups-browsed (default
       printer or still having jobs) and before restart of
       cups-browsed the server's DNS-SD-provided has changed.
     - bannertopdf: Support PDF forms as banner template. This allows
       especially internationalized banner pages. Forms can contain
       fields for any CUPS/IPP value and get automatically filled
       Thanks to Andrew V. Stepanov from ALT Linux (Bug #1170,
       also first step to fix Ubuntu bug #1196986).
  * Removed hard dependency of cups-browsed on avahi-daemon, demoted Depends: to
    Recommends: and removed "on started avahi-daemon" from the "start on ..."
    rule in /etc/init/cups-browsed.conf (LP: #1242185, LP: #1178172).
 -- Till Kamppeter <email address hidden> Mon, 10 Mar 2014 13:40:06 +0100

[Till Kamppeter (till-kamppeter)]

Do not worry about the CVE references. These are other bugs fixed by cups-filters 1.0.47. This bug is not a security vulnerability.