Sunday, August 24, 2014

Brother HL-2275DW

Links: Arch instructions :: Brother Network Guide (PDF)
As always, handy commands:
# lpstat -o
# cancel -a
Cancel -a sometimes doesn't work. In that case, one must individually cancel each named printjob, eg "cancel Brother-001", "cancel Brother-002", etc.

USB connection (10 minutes)

Connect a known-good printer using a USB cable. Turn on the printer. Next, go to this Arch page which lists the connection steps. Here is an abbreviated version, but note there are a few problems in 2015:
  1. I have CUPS but a2ps is also needed: #pacman -S a2ps.
  2. Reboot (or use systemctlto make sure CUPS daemon loads and is running. If users have good knowledge of systemctl command, check CUPS with systemclt or simply run any CUPS command and see what happens, eg...
    $ lpstat -p
    lpstat: Bad file descriptor
    ...indicates CUPS is not yet running.
    # systemctl list-unit-files |grep -i "cups"
    org.cups.cupsd.path enabled
    cups-browsed.service disabled
    org.cups.cups-lpd@.service static
    org.cups.cupsd.service enabled
    org.cups.cups-lpd.socket disabled
    org.cups.cupsd.socket enabled
    The lpd-socket is disabled, because I'm not on a network. It's not necessary. For normal stand-alone usage in this kludge, I only need cupsd.service. So I disable any lpd (network) services, browsed services, etc.
    # systemctl disable org.cups.cups-lpd@service
    # systemctl start org.cups.cupsd.service
    Now I can browse to the CUPS administration page (http://localhost:631). CUPS is running.
  3. $ yaourt brother-hl2270dw
  4. Navigate to CUPS: http://localhost:631.
  5. Click the Administration tab then click the Add Printer button. The username is "root" and the password is the root password of the user's computer. Follow the steps.

USB connection [fail version (4 hrs)]

I went to, typically helpful with Brothers, but this time filled with gobbledy gook and an empty PPD. The order of installation was supposed to be the printer and then the cupswrapper.
  1. Downloaded and unpacked the DEB's for the cupswrapper and the lprdriver. This was weird, since no "cupswrapper" is typically needed for a Brother, just a PPD.
  2. Found the PPD in the kludge of unpacked folders, rooted up and copied the PPD as /usr/share/cups/model/brother.ppd, then chowned it to 0:0 and chmodded it to 755
  3. # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd
  4. restarted CUPS and attempted to print. At first it looked promising, but then it exited, unable to locate the file, "/usr/lib/cups/filter/brother_lpdwrapper_BrGenML1". That file was in the unpacked kludge and I copied it to /usr/lib/cups/filter/, and chowned it to 0:0. Restarted CUPS and tried another print but received "waiting for printer to become available" status message.
  5. Verified the "Brother" entry generated during installation in /etc/cups/printers.conf looked normal. No obvious problems.
  6. Forced a testprint... cat /etc/printcap |lp -d Brother. Not working, so lpadmin -x Brother

WiFi connection


Friday, August 8, 2014

[solved] yet another CUPS related failure -- interference with xsane.

We've all encountered the problem with Xsane where it fails to detect a properly attached USB scanner. Many times this is due to an error in permissions around the scanning group -- the scanner will only be detected as root. Here's a variant: a detection fail in both root or user modes due to CUPS. In my system, if CUPS is running, the scanner cannot be detected in user or root. No informative error message explaining this will be displayed.

There are many ways to determine if the CUPS daemon is running, most involving root. The fastest way is to remember "I just used the printer", but another way from user-space is:
$ lpstat
lpstat: Bad file descriptor
lpstat returns this message when CUPS is not running, and will return a blank line if CUPS is running.

Depending on one's distribution, disable CUPS with...
# systemctl stop cups
Once CUPS is deactivated, Xsane should again detect the scanner in user mode if permissions are properly set.

CUPS accesses stand-alone boxes through loopback privileges into localhost and the CUPS daemon runs under root. Looping-back has associated permission locks which apparently block USB detection, not sure. Anyway, turn CUPS off and scan normally.

Editorial: Since the majority of Linux users are stand-alone users with non-network printers, I consider it a conceit of CUPS developers not to have created a simple stand-alone variant which doesn't need the spaghetti or security issues of loopback privileges. When one considers that the CUPS code is 20 years mature, that its PPD's are actively updated by others, and that only a few lines of code are likely necessary to access USB ports, it becomes annoying. Currently, many CUPS installations require more manipulation of groups than most Linux users possess. More importantly are the security liabilities created by loopback access. Few advanced users, and probably no average users, possess the significant PAM, LDAP, port scrambling, ipchains, etc, knowledge to be certain they've closed less obvious loopback security holes. By the normal desire of Linux users to print, and the lack of any direct stand-alone solution, it's possible many of our systems are quietly compromised.

Thursday, August 7, 2014

[solved] CUPS "rendering completed" errors PT I

Editorial: Stand alone systems with, say, a USB printer attached, are forced to behave like a network when printing with CUPS. This faux-network process on stand-alone systems is one of looping back ("loopback") to one's system ("localhost") -- occasionally a complicated process, depending on port set-up and permissions. Added to this are network security settings since one is opening one's ports "as if" on a network. Entire books are written about this -- it's way over the head of the average user to configure ipchains, LDAP, PAM, port scramblers, and so on properly. Long story short, conflicts are nearly certain on a simple stand-alone printing setup due to CUPS negligence of stand-alone users. I hope that someday, although it's already been 20 years, CUPS developers will humble themselves and address a direct printing solution (in addition to their excellent network solution). /end rant

At any rate, here is a recent fail. I attempted to print a document, but forgot to attach the printer first. CUPS often provides unhelpful or misleading error messages, but no error message was generated. Rather, CUPS continued to display normal status, with a message of "rendering completed". When the printer was attached, it never printed, and no additional documents could be printed. The message that rendering was completed continued to display.

Reinstall (10 minutes)

I verified there was still a PPD in /usr/share/cups/model, located the printer using $ lsusb (in my case 001:004). then...
# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004
Partway through installation is root authentication. The printer installs perfectly and is back to printing.

A tray icon is available as well, but it uses some RAM: /usr/bin/hp-devicesettings

SystemGroup (hours and hours)

CUPS makes a simple conceptual distinction between administrator and user. SystemGroup is a category of users with system-administrator CUPS privileges. Group refers to CUPS users with printing privileges. Although simple in concept and perhaps great on a network, CUPS permissions cause suffering for stand-alone Linux users. Linux systems already isolate administrator (root) and user (user) access. Adding an additional CUPS layer is both redundant and rife with permission overlap possibilities.

First, deal with Group -- add your username to group lp in the system's group administration file, /etc/group. This is a beneficial overlap between Linux and CUPS. CUPS simply looks to see if you're in lp, and you can print.

Now, the harder category, SystemGroup. At the top of /etc/cups/cups-files.conf are the default user settings (typically lp, as just noted). At the bottom of the file are the SystemGroup settings. These are finnicky.
# nano /etc/cups/cups-files.conf
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
User daemon
Group lp

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
SystemGroup sys root

# Do we allow file: device URIs other than to /dev/null? [No]
FileDevice Yes

You want the CUPS SystemGroup membership to be root, so it mirrors your Linux authentications for administration. But unlike the user (lp) level, you don't want a CUPS "SystemGroup" line in your Linux system. That is, don't add a "SystemGroup" group to /etc/group; lp -yes, SystemGroup - no. The latter is CUPS specific only. Confusing.