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

Re: problem adding cups print queue to debian live starting with buster



Thanks, Brian!  Problem now understood with short term fix in hand and
long term fix to be researched.  Inline comments below.

Best regards,

Drew

On Tue, Oct 29, 2019 at 7:48 PM Brian Potkin <claremont102@gmail.com> wrote:
>
> On Tue 29 Oct 2019 at 15:11:18 +0000, Drew Arnett wrote:
>
> > Not exactly cross purposes.  I'm encountering the cups error before I
> > get the chance to even select any specific printer or printer
> > interface.
>
> I had realised what was going on. My inquiry was a gentle one because
> I thought there would possibly be a way round the problem, depending
> on the printer model. It doesn't matter now because the issue is not
> ammenable to being tackled in this way (please see below).

No problem.  For the larger category of problems that come up on this
list, I would
expect that to be a good thing to include in the list of basic things
to check out.

>
> >             Given that this is with Debian live[1], I'll be using it,
> > as I have in the past, with USB or network printers or even a parallel
> > port printer if I have one.  The test setup I have right now for
> > reporting on and researching this problem has both USB and network
> > printers available.  The PC looks like it has a parallel port and I do
> > have a parallel port printer nearby if that helps.  I definitely would
> > like to figure out what's wrong, as Debian live is a useful tool, and
> > it was great when printing worked with it.  (I don't care if it's a
> > real bug or just a dumb user mistake to figure out and share.)
>
> I do not think it is a user mistake. But (see below) Debian live does
> not seem to have kept up with changes in buster.
>
> > The computer, printer, and network haven't changed since this was
> > working with the last Debian 9 point release XFCE live image.
> >
> > Let me walk through the scenario again, with a more step by step
> > detail.  (And please ask if I should flesh out anything even further!)
>
> Your attention to detail makes the issue easy to follow.
>
> > Step 1:  Boot debian-live-10.1.0-amd64-xfce.iso[2].  (Image written to
> > read only thumb drive.  Thumb drive read back to verify checksum and
> > image integrity.)  Packages in this image are listed in [3].
> >
> > Step 2:  sudo apt-get update
> >
> > Note:  no sudo apt-get upgrade this time just to keep it simple.
>
> Upgrading is generally not a bad move.

I agree.  I was just simplifying reproducing the problem.  :-)

>
> > Note:  sources.list only contains one line:  deb
> > http://deb.debian.org/debian/ buster main
>
> Ok.
>
> > Step 3:  sudo apt-get install cups
> >
> > Note:  cups server was not installed, so need to install.  Same with
> > Debian 9 live.  Additional packages apt-get installed are in [3].
> > Could there be something else required?
>
> No printing system on Debian live? Deary me! It should be there and
> functional. Why make users jump through hoops to print?
>

I was fine with Debian 9 live not including cups server package by
default.  Whether or not
to include it in a Debian live image is a separate question.  I
haven't participated in those
conversations, so I don't know all the considerations for such a
thing.  Maybe someone
can ask on the live mailing list.  If it were included, I would prefer
the daemon wasn't started
by default.  Difference between installed and live system alone on
that last point may be
reason enough to not include it.  Folks can build customized live
images, anyway.

> > Step 4:  sudo /etc/init.d/cups start
>
> 'sudo systemctl start cups' here. And, in addition, cups should be
> started when cups-daemon is installed. I am beginning to wonder what
> Debian live is playing at.
>

systemctl.  Yes, I need to update my habits.  :-)

> > Note:  no custom configuration changes before starting cups server.
> > Wasn't required for Debian 9 live.
>
> And should never be required.
>
> > Note:  at this point, cups has 8 lines in /var/log/cups/error_log.
> >
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open
> > \"/usr/share/cups/mime\": Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open \"/etc/cups\":
> > Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open
> > \"/usr/share/cups/mime\": Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open \"/etc/cups\":
> > Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] cupsdLoadBanners: Unable to open
> > banner directory "/usr/share/cups/banners": Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open spool directory
> > "/var/spool/cups": Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open directory
> > "/var/spool/cups/tmp" - Permission denied
> >      E [29/Oct/2019:14:40:35 +0000] Unable to open directory
> > "/var/cache/cups" - Permission denied
> >
> > Those look dire.  New with buster?
>
> I think this is the crux of the issue. apparmor is now installed by
> default. See what the journalctl output gives you.

Ding ding ding.  We have a winner.

I confirmed experimentally that apparmor is what caused the symptoms,
after looking and
seeing the cups error messages in the apparmor logs.  I'll have to do
some homework on
apparmor (has been on my list too long) and do some more investigation
to see what the
most proper solution is.  Is there a command or several to invoke to allow
operation in this case while still using apparmor and using
appropriate granularity?  Or, is
there something I should suggest being changed in the published live
image?  Don't know, yet.

If security isn't a concern, apparmor can be turned off for the cups
profile with:
     sudo apt-get install apparmor-utils
     sudo aa-disable /usr/sbin/cupsd

Yeah, that makes me cringe a little.  So, I will do my homework.

>> > ls -ld on those directories shows:
> >      drwxr-xr-x 2 root root 240 Oct 29 14:40 /usr/share/cups/mime
> >      drwxr-xr-x 5 root lp 220 Oct 29 14:40 /etc/cups
> >      drwxr-xr-x 2 root root 180 Oct 29 14:40 /usr/share/cups/banners
> >      drwxrwx--T 2 root lp 40 Aug 21 07:43 /var/spool/cups/tmp
> >      drwxrwx--- 3 root lp 80 Oct 29 14:40 /var/cache/cups
>
> Nothing wrong there AFAICT.
>
> > Note:  at this point, cupsd process is running as root.
> >
> > Step 5:  XFCE menu:  Applications:  Settings:  Print Settings
> >
> > ps -efd | grep user | grep print suggests that starts:
> >      user      1125   987  0 02:37 ?        00:00:02 /usr/bin/python3
> > /usr/share/system-config-printer/applet.py
> >      user      6263  1075  2 14:47 ?        00:00:01 /usr/bin/python3
> > /usr/share/system-config-printer/system-config-printer.py
> >
> > Note:   The dialog box for the print settings comes up ok.  There is a
> > cupsd access log message showing the connection made without error.
> >
> > Step 6:  In the print settings application, click on add printer.  It
> > asks for username & password authentication.  It did not do this with
> > buster 9.  Cancel.
> >
> > Note:  is there a new need for user to be member of lp or lpadmin
> > group?  user is member of neither.
>
> You are using system-config-printer. Please see
>
>   https://wiki.debian.org/CUPSPrintQueues#scp
>
> > Step 7:  sudo adduser user lp
>
> A security risk. That user can now read what I send to the printing
> system.
>

Not the correct answer.  Agreed.  Only done for trouble shooting experiment.

> > Step 8:  sudo adduser user lpadmin
> >
> > Step 9:  logout and back in.  Verify user now member of those groups as well.
> >
> > Step 10:  start prnt settings application again.  Select add printer.
> >
> > Note:  no longer get the request to authenticate.  However, now get an
> > error dialog popup that says:
> >      "CUPS server error
> >       There was an error during the CUPS operation: 'Internal Server Error'."
> > With cancel & retry buttons.
>
> Probably a consequence of having apparmor on the system.
>
> [...]
>
> Cheers,
>
> Brian.


Reply to: