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 <[email protected]> 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.
