[Pkg-cups-devel] Bug#539156: cups-pdf: installation asks for a password

[Neil Mayhew]

I too am experiencing this problem, and like the others have found it's
related to installing cups-pdf inside a chroot.

There's been a lot of misunderstanding, and I think the real problem has
been missed, which is that the postinst is communicating with the cups
daemon via a TCP connection to localhost, which goes outside the chroot
and communicates with the daemon running on the *host* system. The
purpose of this is to create the necessary queue if it doesn't exist,
but any queue will be created on the *host* not the chroot. It so
happens that the root password is asked for, which is what brings this
issue to light, but fixing the password problem is largely irrelevant
because the postinst still won't work correctly in a chroot, and the
package itself won't work when the system built inside the chroot is
eventually run, because there is no queue. In my project we have had to
install a script that runs on first boot, which forces a reconfiguration
of cups-pdf using dpkg-reconfigure -fnoninteractive cups-pdf which
causes the postinst to be re-run on the live system.

In addition, we have to make sure cups-pdf is installed on the *host*
system to avoid the root password problem. The queue appears to exist
already so lpadmin isn't run and the password isn't asked for. This is
presumably why some people get the problem and others don't. It's not
surprising that the cups-pdf maintainers have cups-pdf installed on
their systems, and so can't reproduce the problem.

In many ways, this is a general cups problem and not just a cups-pdf
problem, because we're not encouraged to configure cups through the
filesystem, and instead are asked to do everything through the daemon,
and this is incompatible with bootstrapping in a chroot.

It's not easy to see how to solve this for cups-pdf. The most obvious
alternative is to update /etc/cups/printers.conf directly and add a
stanza for the queue. I'm not sure if it's OK to do this if the daemon
was in fact running, and it does require cups-pdf to know about the file
format (although this is documented in man printers.conf). Another
alternative would be to start a chrooted daemon listening on a different
port, and shut it down again afterwards, although this should be done
only when running in a chroot. A third possibility would be to schedule
the queue creation for some later time, although it's hard to see how
and when.

A solution for the root password problem, although not for the queue
creation problem, is to temporarily divert /usr/bin/lpstat inside the
chroot and replace it with a script that returns the needed responses
for cups-pdf (lpstat -h localhost -r returns "scheduler is running" and
lpstat -h localhost -v returns "device for PDF: cups-pdf:/"). The
diversion is then removed when the chroot is complete. (It's much
simpler just to install cups-pdf on the host system, of course.)

I'm continuing to think about possible solutions. If I implement
anything I'll post a patch here.