colord - freedesktop.org severe device conflict (printer)

solution

NB: This takes the TN-630 toner cartridge.The TN-660 will work. If the entire drum is replaced, it's the DR-630.

Before describing the problem, here's a process for installing this (04f9:0092) Brother printer. This method is faster than the 3 days I spent understanding how colord had undermined the old reliable install method from a previous post. It's still an hour or two but compare that with salvaging configurations from older setups and losing days.

1. physically connect the printer and lsusb to verify detection.
2. pacman to install colord and cups. At the Brother site, download the RPM and xarchive to extract the PPD (and filter, if you want to go old skool).
3. if it won't archive the RPM, then be sure to install its software # pacman -S cpio.
4. new: $ yay -S brother-hll2315dw. This saves having to harvest, install and do permissions in several directories on executable scripts and data files. This is a 2 day time-saving driver.
5. can rename (or not rename) the PPD to anything "BrotherA.ppd" for example. Open it up and change the default size to 'letter' from 'A4' and/or any other such changes. Save, and put it into /usr/share/model/. Next, do either 6 or 7.
6. (CLI, more fun, less reliable)

   # lpadmin -p BrotherA -E -v [insert the USB URI from lpinfo -v] -m BrotherA.ppd

   The USB URI gained from lpinfo -v may be lengthy and will include a serial number.
7. (GUI, more reliable) Go into CUPS, http://localhost:631/, and "add printer"
   
8. inside the admin page, select "have PPD" and go to it in /usr/share/model to install the PPD from step 4 above.
9. still in the admin page, "maintenance" has the menu to set the device as the default printer.
10. # systemctl restart cups.service

---

the reason this conflict is a 3 day kludge

The solution is above, but here is the days-long struggle. We used to just install the printer with the CLI in about 10 minutes.

freedesktop: systemd and now colord

Freedesktop.org developed systemd of course. It's fairly comprehensive and complex, compared with the old Init.d flexibility of simple config files. Recently freedesktop began taking control of session color options too, and by device. Questionable. But in a horrible design decision, their colord daemon was given control not just of colors, but the DBus, apparently to make device queries/directives for color options. In practice, this means simple software conflicts about colors can lead to Dbus failures. Enter CUPS, attempting to set printer color profiles. Disaster.

CUPS circularity

It's a vicious circle. CUPS needs to write a PERL printer profile which contains (among many other settings) color settings. Meanwhile colord retains absolute control of color by controlling the DBus connection. When CUPS detects that colord has already created a device profile, it aborts its entire profile creation attempt, the one with all the settings for the printer. The result of no CUPS profile/filter is a half-installed printer. The printer doesn't print, and the error message "filter error" appears in the CUPS dashboard.

These errors can also be found in the error_log. If we attempt to install a printer, when colord is operating, we'll see the following:

$ cat /var/log/cups/error_log
W [16/Dec/2022:01:50:02 -0800] CreateProfile failed: org.freedesktop.ColorManager.AlreadyExists:profile id \'BrotherA-Gray..\' already exists

...and we can observe the details of the conflicting profile which colord had already installed...

$ colormgr get-devices
Object Path: /org/freedesktop/ColorManager/devices/cups_BrotherA
Owner: root
...
Colorspace: gray
Device ID: cups-BrotherA

colord's phony paths

It's hard to work with colord because it creates phony paths. The path above, /org/freedesktop/ColorManager/[etc], does not exist. No file is there. This is a "path" only in the sense of it being a line in an XML file or an ICC file. Colord knows how to evalute the line, but there's no file.

As for the XML files which contain the phony paths, these are apprently...

/usr/share/dbus-1/interfaces

... and two homes for the ICC files defining colors, for colord and ghostscript...

/usr/share/color/icc/colord
/usr/share/ghostscript/iccprofiles

order of operations circularity

When we install the printer, colord moves more quickly than CUPS. Colord detects the printer on the dbus and creates a device color profile faster than CUPS can write a CUPS filter. So, CUPS detects an already-made ICC colord color file, logs this color conflict as an error, and exits its entire filter creation. Accordingly we cannot fix the necessary filter later from some other CUPS process: it was never created and thus cannot be modified.

It seems we must either 1) remove colord, 2) configure colord not to create a profile for the printer, 3) modify CUPS to not to create its own color profile or to accept colord's profile, 4) modify the PPD (if possible) not to seek to create a color profile, or possibly to accept colord's profile, 5) place a filter in opt from a duplicate working setup. It might also require some combination. This is a kludge.

As a short preliminary to the 4th option, the simple act of commenting out a PPD's color settings doesn't stop the conflict.

1. remove colord

So let's pull colord, install the printer, then reinstall colord after CUPS has written a filter. It seems that we can do this: CUPS claims to only use colord ICC profiles "optionally".

# pacman -Rsn colord
checking dependencies...
:: cups optionally requires colord: for ICC color profile support

Packages (2) libgusb-0.4.2-1 colord-1.4.6-1

Total Removed Size: 8.49 MiB

:: Do you want to remove these packages? [Y/n]

...meaning CUPS should be able to install the printer without colord installed. Let's delete the error log, reinstall the printer and check for new errors...

# rm /var/log/cups/error_log
# lpadmin -p BrotherA -E -v usb:/dev/bus/usb/lp0 -m brother_HLL2315.ppd
lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.
$ cat /var/log/cups/error_log
cat: /var/log/cups/error_log: No such file or directory

No errors -- seems we're home free. Nope

colord/dbus integration overreach

The printer installed without errors, but attempts to print failed.

FindDeviceById failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files

Yes, CUPS apparently relied on color management from colord as "optional", however reliance on DBus is in no way optional for any application. And, since colord manages both colors and DBus connections to devices, if we take out color management, our printer loses DBus access. The printer cannot then communicate, eg print. A person with a similar problem seems to confirm this. Colord must apparently remain.

2. configure colord

I could find no colord configuration file. Using colormgr, we can delete a colord device profile. But... that's not the problem. The problem is when the color profile (ICC) is created -- which is conflicting with the printer installation. Again, the only time CUPS creates a print filter in /opt/ is its initial read of the PPD file.

3. configure CUPS

The /etc/cups folder has several configuration files.

• /etc/cups/printers.conf: don't edit when CUPS is running.
• /etc/cupsd.conf: I know this file is read during systemctl restart cups.service. I've changed log levels from Warn to Debug before and seen its effects inside /var/log/cups/error_log. It also has permissions. It does not look effective for device install conflicts.

4. modify the PPD

I could find no way to modify the PPD that solved the conflict and created a device. It *is* worthwile to go into the PPD and switch the defaults to "Letter" from "A4" if a person is in the US. Saves having to worry about updates to the device file later on which may disrupt other settings.

5. duplicate a filter

During install, the PPD wants to write a PERL filter to the directory specified in the wrapper shebang. This is the filter that is not written and which causes the print failure.

$ ls /opt/brother/Printers/HLL2315DW/cupswrapper
total 76
drwxr-xr-x 2 0 0 4096 May 24 2020 .
drwxr-xr-x 5 0 0 4096 May 24 2020 ..
-rw-r--r-- 1 0 0 18351 Apr 18 2020 Copying
-rw-r--r-- 1 0 0 15010 Apr 18 2020 brother-HLL2315DW-cups-en.ppd
-rwxr-xr-x 1 0 0 24436 Apr 18 2020 brother_lpdwrapper_HLL2315DW
-rwxr--r-- 1 0 0 7650 Apr 18 2020 paperconfigml1

We can see that the PPD copied itself over and that an executable (755) PERL script (brother_lpdwrapper_HLL2315DW) was written. "Copying" is a license but should also be copied. I put the entire HLL2315DW directory - as is - on a USB key and copied it to the non-printing system. I saved to my installation directory.

HL-L2315DW old-skool steps

Somewhere between my old post and the newest way at the top.

• install colord, cups, do all the download and xarchive of the PPD and filter from the Brother site, described in this post, repeated here in brief
• can rename (or not rename) the PPD to anything "BrotherA.ppd" for example, but the filter (must) keep its full given name. Its only content will be the shebang and the /opt location.
• Attempt to install the printer normally.

  # lpadmin -p BrotherA -E -v usb:/dev/bus/usb/lp0 -m brother2315.ppd

  But now the problem is the URI. This has become extremely finnicky with colord running the dbus. So instead of usb:/dev/[etc] above, use lpinfo -v to get a better USB descriptor. Copy and paste it into the command.
• install and unpack the entire HLL2315DW directory described above and set 755 permissions on appropriate files in the subdirectories lpd, inf, and cupswraper, as well as chown them to "0" (root). This is time consuming so for Arch users, the AUR package will handle this step

[solved] Brother HL-L2315DW USB install ( 04f9:0092)

2022 update: due to evolving colord conflicts with CUPS color-setting, it's best to follow the instructions in my most recent post on this install. There's plenty of relevant older info below, but it probably depends on one's time and inclination whether to move onto the other post or start below.

---

Typical printing links and commands:

• http://localhost:631 CUPS admin page
• # lpadmin -x Brother remove a printer by its installed name, eg. "Brother"
• $ lpinfo -v get info on all connected printers
• # lpstat -o list all print jobs
• # cancel -a cancel all print jobs
• # systemctl [enable/disable/start/stop/restart] cups.service
• /var/log/cups/error_log CUPS error logs

---

The printers are priced $90 clearance (c. 2020) or sometimes $70 refurbished. Refurbished with 2-year warranty is best. Eg, "refurbished" from Wal-Mart ($70), with an Allstate 2 year plan ($6), costs less than a new model ($90) yet with deeper protections, such as free shipping for repairs.

Links: Openprinting.org database :: Brother L2315DW downloads page

---

solution

Go to the Brother L2315DW downloads page and select Linux -> RPM's. Note in the screenshot below that, even though they have three available downloads, both the PPD and LPD are contained in the single 0.2MB PPD download circled in red. The file is hll2315dwcupswrapper-3.2.1-1.i386.rpm.

Use xarchiver to open the RPM and extract its single folder, "opt" Inside opt, I continued drilling down into its subdirectories. I located both necessary files in /opt/brother/Printers/HLL2315DW/cupswrapper/. The CUPS PPD is named brother-HLL2315DW-cups-en.ppd, feel free to rename to [whatever].ppd. As for the LPD, it must retain its name, and you might want to save it (its a Perl script), but you could also just create the file, since its contents are just a single line (see further down).

owner and permission

Ownership will automatically become root b/c these can't be copied into their directories as user -- when you 'su'-up to copy them, they'll move over as owned by root. I have a working system with 755 on the filter but the instructions say it should 751.

• CUPS (PPD) 755 $ chmod 755 file
• LPD text file 751 $ chmod 751 file

locations

• CUPS (PPD) /usr/share/cups/model/foo.ppd
• LPD file /usr/lib/cups/filter/brother_lpdwrapper_HLL2315DW

LPD file

The ONLY way I could get to print was to use default options, which meant creating a custom brother_lpdwrapper_HLL2315DW file. Duplex printing -- an option physically available on the printer -- might be possible from some printer setting, but it cannot be accomplished in the CUPS software without errors that prevent printing altogether. Let the printer report its defaults to CUPS for successful printing. The file which makes CUPS adopt printer defaults is a single shebang line, with no line breaks (it is multiple line below due to column width word-wrapping). Don't forget permissions must be 751.

#! /opt/brother/Printers/HLL2315DW/cupswrapper/brother_lpdwrapper_HLL2315DW

PPD file

The PPD part is like years prior.

• assigned read/execute (5) permissions that have worked with prior PPD's... $ chmod 755 printer.ppd
• copied it to the Arch PPD directory... # cp printer.ppd /usr/share/cups/model/printer.ppd
• verify the USB-attached printer is detected $lsusb
• verify CUPS is running... # systemctl
• install the printer # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m printer.ppd
• alternatively, if having problems, you can use the bus ID's in lsusb and be more specific about the PPD locations as well (all one line):

  lpadmin -p Brother -E -v usb:/dev/bus/usb/lp0 -m printer.ppd

• check it in CUPS http://localhost:631, and verify or assign it default printer
• still in CUPS, verify the printer is awaiting print jobs and not paused
• print a test page
• copy the PPD to one's installation USB key so they needn't download it again for an OS/CUPS re-install

wifi install

Not worth it for a home-use stand-alone printer. It's too flaky. Eg, the next power outage, the WiFi router assigns the printer with a new DHCP address and one has to install the printer again.

somewhat common filter problem

There's a fail where the filter does not print over to the /opt directory.

$ ls/opt/brother/Printers': No such file or directory

The error log looks like this:

cat /var/log/cups/error_log W [14/Dec/2022:22:24:51 -0800] CreateProfile failed: org.freedesktop.ColorManager.AlreadyExists:profile id \'Brother-Gray..\' already exists

What has happened? The printer driver PPD attempted to create a settings file in /opt/brother/Printers/[model], but part of the PPD attempt included setting printer colors. The desktop ColorManager (ICC files) settings from free desktop (files are in /usr/share/dbus-1/interfaces) conflict with the PPD color. Due to the conflict, CUPS aborts creation of the printer configuration file in /opt and then fails to print based on lack of that filter.

These color manager related failures are based on colord ICC profiles for each device and are complex.

colormgr is the command line device for changing colord ICC files.

additional

There's been changes in CUPS, such as requiring the LPR translation file, and PPD's may disappear entirely at some point.

• cannot select Duplex and have it print. If I could, I'd want "DuplexNoTumble". Duplex with tumble inverts the top and bottom of the front/back of a page like for clipboard use. However, the printer only works in single page mode.
• after installation, it's efficient to set it as the default printer in case one has an application that sends to an LPR default, not to a printer name (eg. geeqie).
• Some failures require a CUPS restart...

  # systemctl restart cups.service

[solved] Xerox WorkCentre 5875 on network

This is an interesting case. The only PPD at the Xerox driver site seemed to be embedded in a Windows EXE file -- this may have been complicated to access via, say, Wine. However, I eventually Googled upon an Italian site which provided the generic 5875 PPD, xrx5875.ppd. This version is considered to have only basic functionality, and it was compressed into a ZIP. I was unable to find a full-feature PPD.

Pressing onward, 1) unzip the ZIP to extract the PPD, 2) put the PPD into /usr/share/cups/model, 3) walk to the Xerox and retrieve the machine's IP address from its printer menu (in this case, 192.168.1.101), then....

# cp xrx5875.ppd /usr/share/cups/model/xrx5875.ppd
# chmod 644 /usr/share/cups/model/xrx5875.ppd
# systemctl enable org.cups.cupsd.service
# systemctl start org.cups.cupsd.service
# lpadmin -p WorkCentre5875 -E -v socket://192.168.1.101 -m xrx5875.ppd

After this, if the 5875 is the main copy/printer a person uses at work, they might consider going back into CUPS (http://localhost:631) and setting the Xerox to be the default printer.

[solved] "disabled" printers in cups, "rendering complete" PT II

With an HP printer, if a person clicks "print", but left anything disconnected... they're going to get pissed. CUPS should simply print the job once the printer cable is reconnected. Yet instead of helpfully just printing later, CUPS is much more likely to invoke TWO horrible-to-undo problems... simultaneously.

1. CUPS invokes a "disabled" status for the printer and does not notify the user directly. When the printer is reconnected, the document does not print, but the CUPS icon will only (unhelpfully) indicate "rendering complete" with a green "pause" status for the printer.
2. A person thinks, "I just need to delete the document and try again now that the cable is connected". YES, you'll have to delete the document from the queue or the problem can't be fixed. (Use lpstat -o to get the job number and then cancel [job number] to eliminate it from the queue, or just cancel -a for all). NO, the problem is not yet fixed, and if you try to print again, you need to delete those attempts as well. I suggest cancel -a, then re-enable the printer using one of the two options below.
   

option 1 (5 minutes)

If a person is extremely fortunate, CUPS was installed with CUPS-specific permissions and group categories aligned. There are three layers to these, the first layer being correct permissions for loopback/localhost. Users can check this by attempting to access the CUPS browser-based administration page, running out of port 631, ie, http://localhost:631/. If that works, attempt to clear the disabled printer status as follows.

• Find your paused printer and click on it.
• Under the "maintenance" options for that printer, click on "resume". This is what re-enables the printer.
• Authenticate to activate changes. Typically the user is "root" and then root's password.

At this stage, printing should work again. If authentication failed, either skip to Option 2 below, or take the time* to untangle the group/member permissions (these are the second and third layers of CUPS configuration -- see "cups printer permissions" below) and then go back to the CUPS administration page, once complete.

*an entire afternoon

option 2 (15 minutes)

Remove and reinstall your printer, which hopefully is not an HP. Find your USB port for the printer (lsusb) and then, eg...

# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004

If not an HP printer, then you will likely never have this "disabled" printer problem, but if you do have to reinstall a non HP printer, then the easiest way I've found is, eg...

# lpadmin -x Brother # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd

summary

1. Cancel all print jobs. The fix might work without this, but it's unlikely. Find print job numbers using # lpstat -o and then # cancel [print number], one by one. You will see no change yet in the "rendering complete" status, but print jobs need to be cleared for the "rendering complete" status to subsequently be cleared.
2. "resume" the printer in the CUPS browser interface (if available), or remove and reinstall the printer using the terminal. Either way, "rendering complete" should disappear at this step.
3. Verify that CUPS changes have succeeded by attempting to print or, in a terminal, type "lpstat -p": the printer name should be there and have a status of "idle".

cups printer permissions (in progress)

Users will often only learn their CUPS configuration is misaligned when CUPS authentication fails at the final step of a long process that otherwise seemed to be successful. Any or all of the layers below can be the cause of the problem. Layer 1: loopback/localhost Sadly, CUPS is a network, not a standalone, print server. This means one must disable a percentage of their loopback protections if they want to use CUPS and the CUPS administration page. Outrageous, but true. Loopback is not dealt with on this page. Layer 2: groups

Layer 3: permissions Layer 4: /etc/cups/cups.conf (not always) Most times, nothing needs to be done to this file. When it does, the most typical adjustment involves.

[solved] (kinda) magical cups disappearance

Edit: I eventually rebooted after the CUPS reinstall and ran

# systemctl list-unit-files |grep cups

This time, and I'm not sure why, CUPS units appeared. One unit was org.cups.cupsd.service. Of course! A more complicated name for the service... how could I not guess this? So now, instead of the simpler...

# systemctl start cups

...we now have the impossible to remember...

# systemctl start org.cups.cupsd.service

...thanks a million, CUPS team. More keystrokes and slips of paper, perhaps that's the Linux legacy. At least this one is solved for now.

Edit 2: Evince not printing. Everything appears fine, but only blank pages result. Check it with a direct print. First command to get a list of the printer names, second command to directly print the file. In this case, suppose the name of the printer is "Foo", and the file to be printed is "somefile.pdf"...

# lpstat -p
# lp -d Foo somefile.pdf

If it prints this way, but not in Evince, it's got the f*cking bug.

---

I recently (12/5/2014) updated Arch and CUPS disappeared. It wasn't even there in the list of units. I ran...

# systemctl list-unit-files |grep -i cups
org.cups.cupsd.path

...which is just the CUPS scheduler, so no printers appeared. (The reason to use list-unit-files is it reveals any units, enabled or disabled). A check with

# pacman -Ss cups

showed cups was already installed. I reinstalled it, but still no appearance in the systemd list. Hmmm...

startup service

Then I recalled I'd made a custom startup service to remove the realtek module so it wouldn't continue sending errors. Could this be the problem?

# cat /etc/systemd/system/foostartup.service
[Unit]
Description=startup actions

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/sleep 10s
ExecStart=/usr/bin/rmmod ums_realtek

[Install]
WantedBy=multi-user.target

But no, there was nothing in there which would effect CUPS.

Brother HL-2275DW

Links: Arch instructions :: Brother Network Guide (PDF)

---

As always, handy commands:
LIST OF PENDING PRINT JOBS

# lpstat -o

CANCEL ALL PENDING PRINT JOBS

# 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 openprinting.org, 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

Unattempted

[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.

[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.

cups - hp office jet pro 8500a - 12 hours of fail in Lubuntu

Links: open printing.org   scroll down for tarball link   uninstall hplip   hp-setup options
Note this may also play HEAVILY into encountered problems with Ubuntu/Lubuntu printer addition: gnome keyring fiasco

---

So a year and a half ago, I added this printer in Minislack/Zenwalk. In 2013, I'm into Lubuntu, mostly for an updated set of libraries for the time being. I know Lubuntu (so far) uses usblp for usb printers so it should go OK. One thing, I'm expecting to compile my core applications as I've already noticed from Ubuntu/Lubuntu versions of avconv and ffmpeg, that they seem to be watered down. I suppose they have to be for such a popular distribution, so I keep my expectations for this distro to having a recent set of libraries for compiling. Back to our printer story... scroll down to Pt 3 for installation.

Pt 1 Groundwork

• HPLIP has apparently changed to where it must now be compiled to get the .ppd's out of the source? (Edit 2013-03-24 after unpacking the HPLIP source, the .ppd's are available, but in a compressed "gz"format, eg "hp-officejet_pro_8500_a910.ppd". Select and use as needed (chmod 644 the file) without proceeding further with HPLIP compilation. Save both "hpcups" and the "hpijs" versions, since hpcups is new, its rasterization is different, and YMMV. If one proceeds with the HPLIP installation, the gz'ed ppd's are also placed into /usr/share/ppd/HP
• Before doing so, use Synaptic to install developer versions of libjpeg, libcups, libusb1, and libsane to avoid ./configure fails. My final HPLIP configure line was $ ./configure --prefix=/usr --enable-lite-build --disable-network-build. I only needed scanning and printing, and via a USB connection.

Pt 2 errors

This make proceeded along for a while until exiting with

prnt/hpcups/CommonDefinitions.h:43:25: fatal error: cups/raster.h: No such file or directory

I installed apt-file (# apt-get apt-file find) and sought out the raster.h code. Sure enough, it was located:

$ apt-file search cups/raster.h
libcupsimage2-dev: /usr/include/cups/raster.h
lsb-build-base3: /usr/include/lsb3/cups/raster.h

So accordingly...

# apt-get install libcupsimage2-dev

...and back to the compiling. I have to hand it to whomever came up with the excellent idea of apt-file. The remainder, including # make install, appeared to go normally.

next errors

To check the installation...

$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Perhaps some library linking did not go well, $PATH was not updated, or files were installed into a non-standard location for the PATH or CUPS. The latter is what happened during a prior HPLIP install in 2011.

$ ls /usr/bin |grep hp
dvihp
hp-mkuri
php
php5
pitchplay

Not encouraging.

$ which hp-check
$

Not encouraging.

$ find -name hp-check
$

Not encouraging.

# service cups restart
cups stop/waiting
cups start/running, process 11411
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Not encouraging.

# reboot
$ hp-check -t
The program 'hp-check' is currently not installed. You can install it by typing:
sudo apt-get install hplip

Not encouraging.

uninstalling HPLIP

Link: Uninstall instructions. From the installation directory...

# make uninstall
( cd '/usr/share/cups/drv/hp' && rm -f hpcups.drv )
( cd '/etc/cron.daily' && rm -f hplip_cron )
( cd '/usr/share/hal/fdi/preprobe/10osvendor' && rm -f 20-hplip-devices.fdi )
( cd '/usr/share/ppd/HP'...all ppds)
( cd '/etc/udev/rules.d' && rm -f 56-hpmud_support.rules 86-hpmud_plugin.rules 56-hpmud_add_printer.rules 55-hpmud.rules )
( cd '/usr/share/doc/...various docs.)
( cd '/usr/share/doc/hplip-3.13.3/styles' && rm -f css.css )
( cd '/usr/share/doc/hplip-3.13.3/images' && rm -f favicon.ico print.png toolbox_actions.png toolbox_fax.png toolbox_print_control.png toolbox_print_settings.png toolbox_status.png toolbox_supplies.png xsane.png )
( cd '/usr/share/doc/hplip-3.13.3' && rm -f COPYING copyright README_LIBJPG )
( cd '/usr/lib/cups/backend' && rm -f hp )
( cd '/usr/bin' && rm -f hp-mkuri )
( cd '/usr/lib/cups/filter' && rm -f hpcups )
( cd '/usr/lib/cups/filter' && rm -f hpcupsfax )
( cd '/etc/hp' && rm -f hplip.conf )

This is where HPLIP had been installed. I don't believe the HAL issue will be important, but we'll see. Additionally, from the uninstall, we have some idea what libraries were installed and why they might not have been located...

/bin/bash ./libtool --mode=uninstall rm -f usr/lib/libhpmud.la'
libtool: uninstall: rm -f /usr/lib/libhpmud.la /usr/lib/libhpmud.so.0.0.6 /usr/lib/libhpmud.so.0 /usr/lib/libhpmud.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/libhpip.la'
libtool: uninstall: rm -f /usr/lib/libhpip.la /usr/lib/libhpip.so.0.0.1 /usr/lib/libhpip.so.0 /usr/lib/libhpip.so
/bin/bash ./libtool --mode=uninstall rm -f '/usr/lib/sane/libsane-hpaio.la'
libtool: uninstall: rm -f /usr/lib/sane/libsane-hpaio.la /usr/lib/sane/libsane-hpaio.so.1.0.0 /usr/lib/sane/libsane-hpaio.so.1 /usr/lib/sane/libsane-hpaio.so
( cd '/usr/lib/cups/filter' && rm -f pstotiff )

We'll see if we can get by without these libraries, eg, may not be able to do scanning. Still, simple printing, to start. A decent PPD should be sufficient.

Pt 3 Printer Installation (10 minute)

Note: "udevmonitor" is now "udevadm monitor".
1. Uncompress the ppd wherever you find it as a .ppd.gz from the HPLIP source (no need to compile HPLIP)
2. Copy it to where it can be found and chmod it.

# cp hp-officejet_pro_8500_a910.ppd /usr/share/cups/model/1sttry.ppd
# chmod 644 /usr/share/cups/model/1sttry.ppd

3. Verify you the user are in the groups lp and lpadmin, eg via "$ groups" or "# userconfig"
4. Verify the file /etc/cups/cupsd.conf has the line (or add it and restart CUPS):

FileDevice Yes

5. Run # udevadm monitor
6. Connect printer into USB, write-down dev address eg, usb:/dev/usb/lp0 that appears.
7. Be sure CUPS is running, eg # service cups restart
8. Add the printer to that USB address.

# lpadmin -p hp8500 -E -v usb:/dev/usb/lp0 -m 1sttry.ppd

9. Print, profit
10. If problems occur, see my post from 2011. You might have to uninstall the printer and try a different PPD or a different location for the PPD. The command to cancel current print jobs is # lprm -, the command to remove the printer (eg, named 'hp8500' above): # lpadmin -x hp8500. Also # lpstat -v is your friend.

One additional error

Uninstalling the HPLIP libraries earlier above did come back to bite. Everything installed properly, but when attempting to print, an error: "/usr/lib/cups/filter/hp/cups not available: No such file or directory". I then reinstalled HPLIP but installed PPD manually. Appeared all good, but print jobs gave error that printer was waiting to become available. Looked into /var/log/cups/error.log, and noted the following

The name org.freedesktop.ColorManager was not provided by any .service files

This appears to be a common error. By now, I also saw a lot others pissed off about the various security (non)interactions around loopback security and their distro. For example, this person's SuSE rant.

Incidentally, I noted that, in each case, a gnome keyring error appears, stopping communication with the printer. Apparently, a person has to hack their own laptop(!) for normal use if they use Ubuntu/Lubuntu. The roots of gnome-keyring persist into PAM, of course, and the LDAP abortion in their own system. To avoid contributing to my own productivity loss past the 12 hours already lost here, I eventually installed the HP5800a with "apt-get hplip". At some point, I will return to Slackware but, before doing so, I will attempt to euthanize gnome-keyring, PAM, and whatever other interconnected encryption garbage is in this distro when I have a few days to spare and see if a printer can be attached.

Again, adding a printer is typically a console job of 10 minutes, but I just gave up and let the immense Ubuntu RAM-killing daemon colluge do it for me after 12 lost hours. Google "cups pam" and you'll see why I gave up.

lpadmin

Lpadmin is part of CUPS and doesn't work when CUPS is not running.

GET A LIST OF PENDING PRINT JOBS BY INSTALLED PRINTER NAME

# lpstat

CANCEL ALL PENDING PRINT JOBS

# cancel -a

PRINT A TEST PAGE (eg, the man page for lpadmin)

# man lpadmin | lp -d HP8500

cups - hp office jet pro 8500a

Links: open printing.org   scroll down for tarball link   uninstall hplip   hp-setup options

---

Hey, I like printer installations the easy way, typically in about 10 minutes or less with lpadmin and CUPS from the command line. The 8500A, however, is an HP printer. HP documentation states that HP translation software (HPLIP), in addition to CUPS, is required for all HP printers operating with Linux. Nevertheless, many HP printers work without HPLIP, once the .ppd file can be installed. I attempted to install this HP8500A without HPLIP, and it worked. The description for the process is in Part 1 below. Parts 2 and 3 document the installation of the printer using HPLIP. Some steps in Parts 2 and 3 are repeats from Part 1.

Pt 1 What worked (w/out HP software)

short version

• Download the .ppd, even if it's inside a larger HPLIP release. Discard the remaining HPLIP software
• Put the .ppd into /usr/share/cups/model so lpadmin can locate it
• Add FileDevice Yes to /etc/cups/cupsd.conf if it's not already there and restart CUPS to read the change
• Add the user to group lp (or lpadmin -- check /etc/cups/cupsd.conf to verify the group), and be sure the system can see the printer in basic user mode, eg, the printer should be visible in $ lsusb
• Using ///dev/usb/lp0 seems to work better than usb:/dev/usb/lp0 in the installation line

long version

1. Download the latest HPLIP source tarball. Why? CUPS needs a .ppd (printer information) file for any printer it operates, HP or otherwise. However, the installation wizard is unnecessary. Only the source tarball is necessary. From the tarball, extract the relevant .ppd and discard the remaining 20MB. That is, after extracting the HP8500A ppd (hp-officejet_pro_8500_a910.ppd), discard the remaining HPLIP software.

Update 3/2013: The tarball appears to no longer be easily available. Substituted is the annoying "hplip-3.13.3.run (21.7 MB)", which most pages link to. I eventually located a tarball via this page, after scrolling down a bit.

2. During install, lpadmin searches for .ppd's in directory /usr/share/cups/model. Root up, copy the HP5800A .ppd to that directory (and chmod 644 the file) so it will be able to find it. Alternatively, in Ubuntu, these may be placed into /usr/share/ppd/cupsfilters.

3. In order to use lpadmin, activate CUPS...

# service start cups

...then fire-up udevmonitor, plug the printer in to the USB, note its /dev ID, and add the USB printer to that /dev address

# lpadmin -p hp8500 -E -v usb:/dev/usb/lp0 -m hp-officejet_pro_8500_a910.ppd

Or, if the printer is on a network, find its net address and then...

# lpadmin -p hp8500 -E -v socket://192.168.1.101/printer -m hp-officejet_pro_8500_a910.ppd

4. The above is all that is typically required. However, this printer was not detected by CUPS following installation. The HP printer apparently broadcasts in such a way that it does not allow detection without root. That is to say, if one runs $ lsusb , the HP is not found. The printer is found with # lsusb. This is a group permissions issue, so I ran $ groups and, sure enough, I was not a member of the lp group at the user level. Solution, uninstalled the printer...

# lpadmin -x HP8500A

...and added myself as a user to the lp group using the GUI invoked from

# userconfig

There's some file that can be sourced after that to update the system, but I just rebooted so save effort. I installed again and the printer was detected.

5. Attempting to print, however, the printer hung -- "processing" the file without printing it. I recalled I also had an installed USB Brother that had been working. A look at the list of the installed printers to see if there were differences revealed:

# lpstat -v
device for Brother: ///dev/usb/lp0
device for hp8500: usb://dev/usb/lp0

Note the Brother device shows a slightly different /dev URL than the HP. I uninstalled the HP again (lpadmin -x), and reinstalled using ///dev/usb/lp0. This led to an error

# lpadmin -p hp8500 -E -v ///dev/usb/lp0 -m hp8500a.ppd
lpadmin: File device URIs have been disabled! To enable, see the FileDevice directive in "/etc/cups/cupsd.conf".

Accordingly, opened the file /etc/cups/cupsd.conf
and added the line

FileDevice Yes

Restarted CUPS so the conf file would be read. Uninstalled the printer and installed it again

# lpadmin -p hp8500 -E -v ///dev/usb/lp0 -m hp8500a.ppd

Prints without problems.

Pt 2 What worked (HPLIP and other HP software)

First, proceed the first part of Part 3 below to make sure HPLIP is properly installed. This may be an extensive project requiring software updates and other bullsh*t.

Following HPLIP installation, you need to be certain the HP printer is detectable at the user level. Why? The program hp-install is necessary for installation and it must be run at the user level, not the root level. If hp-install cannot detect the printer, it cannot install it. But the HP printer broadcasts in such a way that it does not allow detection without group membership or root. That is to say, if one runs $ lsusb , the HP is not found, but it IS found with # lsusb. To correct the permission, run

# userconfig

to invoke the groups and users GUI. Add the user to the lp group and reboot. Check that the printer is detected at the user level:$ lsub If all is OK, note the USB address, which in this case was 002:003. Now you can install the printer:

$ hp-install -i --auto 002:003

Ater the installation, there is a short authentication step requiring root, but this is the final step. It should print.

Pt 3 What DIDN'T work (HPLIP and other HP software)

HPLIP v.3.11.7 goes inta...

Who knows? Some directories somewhere in my system. Did a standard configure, which dumped-out and told me I couldn't do a network build without SNMP installed. Annoying and unnecessarily prohibitive, since all an Ethernet printer needs is a TCP/IP stack, which was already there, and I wasn't going to rearrange my SNMP installation just for HPLIP requirements. But what could I do -- the HPLIP programmers had hard-coded the SNMP requirement? Ok then, decision made: forget networking. So, disabled network capability, then completed a standard make and # make-install. Again, no telling into which directories.

will HPLIP work?

Come on, you know it didn't. The first error looked like this

Filter "hpcups" for printer "HP8500A" not available: No such file or directory

A guy, ccin1492, on Linux Questions found that his similar problem was related to where HPLIP was putting its files:

It appears that HPLIP is putting stuff in one directory /usr/lib64/cups/filter, but CUPS is putting stuff in /usr/lib/cups/filter. So to fix my problem I linked the following files into /usr/lib/cups/filter so CUPS can see them.

hpcups*
hplipjs*
pstoraster*
pstopxl*

And so on. In my installation, it appeared that the HPLIP was putting stuff in to /usr/lib/cups/filter, but that's not where CUPS was looking. CUPS was looking for shiat where it usually does, in /usr/share/cups/model. So I made soft links to that directory but I still had no luck. Next thing, I ran hp-check. Here are the errors it located (leaving out the successes)

$ hp-check -t
Checking for dependency: CUPS DDK - CUPS driver development kit...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: libnetsnmp-devel - SNMP networking library development files...
error: NOT FOUND! This is a REQUIRED dependency. Please make sure that this dependency is installed before installing or running HPLIP.

Checking for dependency: PIL - Python Imaging Library (required for commandline scanning with hp-scan)...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: PolicyKit - Administrative policy framework...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Checking for dependency: PyQt 4 DBus - DBus Support for PyQt4...
error: NOT FOUND! This is a REQUIRED/RUNTIME ONLY dependency. Please make sure that this dependency is installed before installing or running HPLIP.

Checking for dependency: Reportlab - PDF library for Python...
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

How wonderful to have HPLIP working for me, right?

removing HPLIP

Let's get this garbage out and try something else. To remove HPLIP, I first had to figure out where it was. Looking around (another half hour), the two main places appeared to be /usr/local/bin and /usr/local/share/hplip. Accordingly, I destroyed them.

# rm -r /usr/local/bin/hp*
# rm -r /usr/local/share/hplip
# rm -r /usr/local/share/cups/drv/*

I left hpcups, in case I needed that for the ppd I intended to retrieve from open printing.org. I knew some of the HP ppd's at OpenPrinting were standalone instead of HPLIP dependent. Digging into the OpenPrinting HP8500A documentation though, I was still eventually routed back to HPLIP. But I didn't give up. I figured that, if I could just edit an HP ppd enough to make it work with cupsd instead of requiring hpcups, I'd be set. And I would have been set, but no, inside the HP8500A ppd, it makes proprietary HP printer calls which CUPS does not independently recognize. Dang it, back to needing HPLIP or just getting a Brother printer (they all work like a charm with CUPS).

hplip again

By this point, I had wasted more than 12 man hours configuring the "free" HP8500A I had access to, when I could have instead bought a network compatible Brother HL-2270DW for $100. Really smart. Anyway, the first step to returning HPLIP was deleting my manual installation of the ppd

# lpadmin -x HP8500A

Next, recompiling. This time, I didn't bother with fax, scanner, copier, or network capability, hopefully to make it a simple HPLIP install for basic USB printing.

$ configure --disable-network-build --disable-hpijs-only-build --disable-qt4 --enable-qt3 --disable-fax-build

After installation, received errors

$ hp-setup
Traceback (most recent call last):
File "/usr/local/bin/hp-setup", line 45, in
from base import device, utils, tui, models, module
File "/usr/local/share/hplip/base/device.py", line 39, in
import status
File "/usr/local/share/hplip/base/status.py", line 45, in
import hpmudext
ImportError: No module named hpmudext

Look for hpmudext.

$ find -name hpmudext*
./usr/local/lib/python2.6/site-packages/hpmudext.so
./usr/local/lib/python2.6/site-packages/hpmudext.la

It's in there, so for some reason HPLIP can't find the directory or doesn't recognize the version. Check python version.

$ python -V
Python 2.6.1

Noting here, that Python 2.6.1 goes with HPLIP version 3.5.10-4 , but I have HPLIP version 3.11.7 compiled and installed. It might be advisable to remove the newer version of HPLIP I have installed and replace it by compiling and installing the older 3.5.10-4 version of HPLIP, but the printer (HP8500A) is a new model and there is no ppd support in the older 3.5 HPLIP. I'll need that newer HPLIP to interface with the printer. What to do? I could save the newer ppd and attempt to use it with the older HPLIP, I suppose. First lets make a soft link to where HPLIP is finding other modules and see if it can locate hpmudext.so there.

# ln -s /usr/local/lib/python2.6/site-packages/hpmudext.so /usr/lib/python2.6/hpmudext.so
# ln -s /usr/local/lib/python2.6/site-packages/hpmudext.la /usr/lib/python2.6/hpmudext.la

Better, but still errors.

$ hp-setup
warning: CUPSEXT could not be loaded. Please check HPLIP installation.

Look for cupsext.

$ find -name cupsext*
./usr/local/lib/python2.6/site-packages/cupsext.so
./usr/local/lib/python2.6/site-packages/cupsext.la

Appears same problem there as with hpmudext, so lets make softlinks for cupsext too.

# ln -s /usr/local/lib/python2.6/site-packages/cupsext.so /usr/lib/python2.6/cupsext.so
# ln -s /usr/local/lib/python2.6/site-packages/cupsext.la /usr/lib/python2.6/cupsext.la

Also made similar links to scanext and pcardext, to complete the four Python extension links. Now let's try to run hp-setup again.

$ hp-setup

HP Linux Imaging and Printing System (ver. 3.11.7)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-9 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

error: PyQt not installed. GUI not available. Exiting.
warning: Qt/PyQt 3 initialization failed.
error: hp-setup requires GUI support (try running with --qt4). Also, try using interactive (-i) mode.

Appears we have functionality using the softlink hack, but no GUI. We can live without a GUI: not into engineering a PyQt install. So let's attempt "interactive mode" for another half page printout of information.

$ hp-setup -i

HP Linux Imaging and Printing System (ver. 3.11.7)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-9 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

(Note: Defaults for each question are maked with a '*'. Press to accept the default.)


Using connection type: usb

error: No device selected/specified or that supports this functionality.

Have to read up on hp-setup command options apparently. Here's a good page for hp-setup commands that I'll also put above in the links. Meanwhile, let's go purchase a USB cable - getting close.

permissions

Along with its other problems, HPLIP brings a permission complication. The HP printer broadcasts in such a way that it does not allow detection without root. That is to say, if one runs $ lsusb , the HP is not found. The printer is found with # lsusb. But this means hp-install, which is run at the user level, cannot locate the printer and install it until this permission is addressed. I ran $ groups and noted I was not a member of the lp group.

# userconfig

Added the user to the lp group -- there's some file you can source after that to update it, but it's easier just to reboot. Following the reboot, the user level $ lsub found the printer at 002:003. At that point, I simply ran

$ hp-install -i --auto 002:003

This successfully added the printer, the only pause being to authenticate as root during the final step. I have a Brother also installed (CUPS only) and this is how the print options appeared when I selected "Print" in a document menu.

On the CUPS side, cupsd also apparently allowed HPLIP to write into the configuration file /etc/cups/printers.conf. The working configuration file (including the Brother):

# cat /etc/cups/printers.conf
Printer configuration file for CUPS v1.3.9
# Written by cupsd on 2011-09-10 15:16
<Printer Brother>
Info Brother
DeviceURI file:///dev/usb/lp0
State Idle
StateTime 1303970446
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>
<Printer Officejet_Pro_8500_A910>
Info Automatically setup by HPLIP
Location
DeviceURI hp:/usb/Officejet_Pro_8500_A910?serial=3VN0DGP2XN
State Idle
StateTime 1315693016
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

cups - brother mfc-8840d

Links:  Openprinting.org (Printing)      Sane project (Scanning)    Brother (manufacturer)

---

pt1: printing

A friend has an older Brother printer, the MFC-8840D (device code 04f9:0160), an all-in-one copy-print-fax machine. He mentioned that the machine is reachable via its USB port or via a built-in WiFi card, but neither were apparently operating consistently with his XP box. It piqued my interest because I hadn't previously configured a WiFi printer w/Linux. The MFC8840D seemed like a good place to start -- Openprinting.org noted it has "excellent" performance with Linux.
1. Accordingly, began at Openprinting.org and retrieved the ppd file. Renamed the file "brothermfc8840d.ppd" for ease of use and copied it into /usr/share/cups/model. CUPS locates printer information files in that directory.

2. In order to use lpadmin, turned-on CUPS:

# service start cups

Added the printer:

# lpadmin -p Brother -E -v socket://192.168.1.101/printer -m brothermfc8840.ppd

Printer installed and the /etc/cups/printers.conf file was properly generated. Only remaining task was to retrieve the HOSTNAME and TCP/IP info from the printer and update /etc/cups/printers.conf in a text editor with this info.

3. Walked to printer to retreive info but, ah-hah!, it turned out there was no WiFi in the Brother MFC-8840D. The networking capacity my friend apparently hoped was WiFi is only Ethernet. The printer has 3 ports: USB, Ethernet, and parallel. I went ahead and completed the install using USB so my buddy could determine whether his previous printing problems were in XP or the printer itself.

4. Turned the printer on and connected the USB cable to my laptop, running # udevmonitor to get the port name "/usb/lp0". I then opened /etc/cups/printers.conf and changed the URI to a USB connection:

# cat /etc/cups/printers.conf
# Printer configuration file for CUPS v1.3.9
# Written by cupsd on 2011-04-27 23:00
<Printer Brother>
Info Brother
DeviceURI file:///dev/usb/lp0
State Idle
StateTime 1303970446
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

5. Restarted CUPS so that CUPS re-read the printers.conf file with the updated USB information:

# service restart cups

Prints without any apparent problems. Installation time: 10 minutes. Did not initialize or verify the printer's scanner operation.

pt2: scanning

Links: Howto w/scripts   Howto w/scripts   Gentoo Howto

Looked through the SANE database and noted Linux compatibility with the MFC-8840D is listed as "good". That said, a person can go with a simple or a very involved scanner installation. Below, I include both but break it into two parts. For simple scanning using the Xsane GUI, the simple installation will do. For OCR, specialized file handling, and so forth (all of this is possible), a complete install may be necessary. Before I start on these, some checks and the procedures which apply to both a simple of full install are provided.

Checks  The scanner portion of the Brother can be difficult for the system to detect. These checks provide confirmation of detection and useful information during any stage of the installation. Use freely:

$ scanimage --test
$ scanimage - L
$ brscan-skey -l
$ sane-find-scanner

Necessary  

• Verify "brother" is in the list in the /etc/sane.d/dll file. If it is not, add it.
• The sane configuration directory must have a "brother.conf". Check with ls /etc/sane.d/. If there is no brother.conf, make one. Get the printer device number using $ sane-find-scanner and then make the file:

# nano /etc/sane.d/brother.conf
usb 0x4f9 0x16e
option connect-device

Preference: I run programs as "user", not "root", so I changed the permissions for this device by simply moving it into my user-level 'lp' (printer) group. First found the device in my rules:

# cat /etc/udev/rules.d/30-scanners.rules |grep "Brother MFC-8840"
# Brother MFC-8840D

Second, went to line 915 and changed permissions and groups. Before the changes:

ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="0160", MODE="0664", GROUP="scanner", ENV{libsane_matched}="yes"

After changes:

ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="0160", MODE="0666", GROUP="lp", ENV{libsane_matched}="yes"

With these in place, moved on to the software.

A. Simple Installation ~ 10 minutes

A1. Proprietary Brother scanning software. This is supposedly freely available at the Brother site. The Brother site maintains only .rpm/.deb files. I run Slackware, so I used rpm2tgz to convert and then installpkg:

$ cd downloads
$ rpm2tgz brscan*
$ mkdir brscan
$ cp brscan-0.2.4-0.i386.tgz /brscan
$ cd brscan
$ su
# installpkg brscan-0.2.4-0.i386.tgz
# exit
$ brsaneconfig (it works)

A2.Check scanner operation:

$ scanimage --test

A3. Open XSane in the menu and scan sh*t.

B. Full Installation ~ 8 hrs

B1. Install the 32 bit brscan.

$ cd downloads
$ rpm2tgz brscan*
$ mkdir brscan
$ cp brscan-0.2.4-0.i386.tgz /brscan
$ cd brscan
$ su
# installpkg brscan-0.2.4-0.i386.tgz
# exit
$ brsaneconfig (it works)

B2. Install the 32 bit brscan-skey.

$ cd downloads
$ rpm2tgz brscan-skey*
$ mkdir brscan
$ cp brscan-skey-0.2.1-3.i386.tgz /brscan
$ cd brscan
$ su
# installpkg brscan-skey-0.2.1-3.i386.tgz
# exit
$ brscan-skey (it works)

B3. Check it:

$ brscan-skey -l
MFC-8840D : brother:bus6;dev1 : USB Not registered
$ sane-find-scanner
found USB scanner (vendor=0x04f9, product=0x0160) at libusb:002:003
$ scanimage -L
device `brother:bus5;dev1' is a Brother MFC-8840D USB scanner

B4. At this point, the scanner scanned just fine, but the jpg was not saved and I was getting the error message:

ERROR: No such file or directory [/usr/local/Brother/sane/brscan-skey-0.2.1-3.cfg]

B5. Must therefor create the file /usr/local/Brother/sane/brscan-skey-0.2.1-3.cfg

# nano /usr/local/Brother/sane/brscan-skey-0.2.1-3.cfg
password=
IMAGE="sh /usr/local/Brother/sane/script/scantoimage-0.2.1-3.sh"
OCR="sh /usr/local/Brother/sane/script/scantoocr-0.2.1-3.sh"
EMAIL="sh /usr/local/Brother/sane/script/scantoemail-0.2.1-3.sh"
FILE="sh /usr/local/Brother/sane/script/scantofile-0.2.1-3.sh"
SEMID=b

B6. Must then create a script for each desired function. This site has samples of all of them. There are limitless tweaks for file size, OCR use, etc etc etc. Can go crazy with this -- the scripts are entirely configurable for nearly any function.

pt3: faxing

No phone available here, but this appears relatively straightforward and the software is likewise available at the Brother site.

CUPS - Wifi Brother HL-2170W

basics (through USB)

Appears there are several steps.
1. Unbox and confirm printer works using test page.
2. The Brother drivers appear to come only in .deb and .rpm formats, so I verified the rpm program was installed (if not, netpkg rpm).
3. Download rpm printer drivers from Brother site, both the cupswrapper and the lprdrivers.
4.Install the lpr driver

# rpm -ihv --nodeps brhl2170wlpr-2.0.2-1.i386.rpm

5. Install the cupswrapper

# rpm -ihv --nodeps cupswrapperHL2170W-2.0.2-1.i386.rpm

6. Verify these have properly installed by finding them in the results from this command:

# rpm -qa

7. Turn-off printer and connect with USB. Turn-on printer.
8. Add printer to CUPS

# lpadmin -p Brother -E -v usb://dev/usb/lp0 -m HL2170W.ppd

9. Restart CUPS

# service restart cups

10. Should work

CUPS - usb HP DJet F300

(HP a1350e)

Zenwalk 5.2
2.3G Athalon X64 two part processor
400 MB Ram
HP Deskjet F300 (USB)

CUPS, good documentation here.

Sketchy CUPS Webtool

I was at my folks house recently for the holidays and installed Zenwalk 5.2, a Slack-based OS that's pretty light. All went well until I attempted to add a HP Deskjet F300 All-In-One. The HP website says support only begins with F310. I figured I could get a workaround going.
1. In spite of (significant) password efforts, you will likely find that the webtool athttp://localhost:631simply rejects any and all passwords, no matter what, when, or why, and will deny you adding a printer, always waiting until the final step in a timely 6-part process to do so. After a couple of lost days working with /etc/cups/cupsd.conf and password, this of course will become ballistically frustrating. The temptation to sledge-hammer the computer will become more pronounced as one realizes the rejection of the CUPS webtool means the printer must be added manually using lpadmin and, like any CLI, it is powerful and simultaneously filled with the potential for damaging errors. One can easily spend days. But what are you going to do - you have to print, right?
2. The ppd file has to be locatable by lpadmin. Put the ones which need to be found in /usr/share/cups/model/ . I renamed the original ppd to dj350.ppd. for ease of loading and made sure it was the proper permission for ppd files "644". Now try this:

#lpadmin -p HP300 -E -v usb:/dev/usb/lp0 -m dj350.ppd 

The printer added easily. If a mistake is made and a PPD file is installed that you later want to substitute with a different PPD file, put the new file in /usr/share/cups/model/ and run the following command:

#lpadmin -p HP300 –P another.ppd

To delete a printer entirely, use the command:

#lpadmin -x HP300

To make certain, you can always check the list of installed printers using:

#lpstat -v

Day 2 (Afternoon/Evening) More lpadmin and configuration files

It may be possible, though unlikely, to work via CUPS web interface. If not, look at the file /etc/cups/printers.conf and note its arrangement. Pay particular attention to this line.

DeviceURI usb://dev/usb/lp0

This critical printer setting must be accurate.

test prints

Test prints are one easy thing from the CUPS web interface; although lpadmin is required to stop testprints, the CUPS interface is an easy way to initiate them. While testing the printer configs, many test prints might be desired. If they don't print, they pile-up in queue and use resources re-attempting. One can't use CUPS web interface to stop prints, so cancel them from lpadmin:

#lpstat -o

provides pending print jobs and the job number eg, "HP1100-1". Then

#cancel HP1100-1

will get rid of the job. Run "lpstat -o" again to verify, if you like.

xfce4 connection

To print from Mousepad and others that use X-settings, xfce printing needs to recognize the CUPS printer. Try printing in Mousepad and see if the CUPS printer is available. If not, configuring xfce4 to CUPS will be necessary. This was simple for me. I simply went to the XFCE menu, then access Settings ->Settings Manager -> Printing System. Once in Printing System, I selected the CUPS network printer and closed the menu. I then opened a Mouspad file to print; sure enough, the CUPS printer appeared in my options.

SNMP HPLIP

SNMP (Simple Network Management Protocol) is a powerful process originally designed to simplify web management. Many processes take advantage of SNMP functionality and one of them is HPLIP

If hp-setup doesn't work, then the road may be long. Try using SNMP to determine if the kernel can see the printer at the nework address:

snmpwalk -Os -c public -v 1 ip.address.of.printer 1.3.6.1.4.1.11.2.3.9.1.1.7.0 

Per this site HP tshoot, the response should be something which shows the manufacturer, or SNMP may not be installed correctly. This means working with the /etc/snmp/snmpd.conf file.

Slackware 12.0 - CUPS network printer

Here's how CUPS worked-out on a couple different systems connected to a wired ethernet LAN, with a printer attached to the same LAN, and wifi access to the Web on each box (dual-homed boxes).

slackware 12.0 - huge.s kernel patched for non-smp
500 MHz PIII
500 MB Ram
--printer--
HP1100 LaserJet
Netgear PS 101 MiniServer
Linksys BEFSR41 10/100 router
RTL8139 type card

What works: install

For most of us, the CUPS webtool at  http://localhost:631
simply never works. Not only this, but it waits until the final step in a timely 6-part process to note the failure. For me, it feels more efficient to add printers manually. Perhaps some day all the permissions will align with the stars and CUPS will work. At any rate, there is no limit to the number of printers we can manually add to our workstation.

Lpadmin is the command, but first prepare the printspace:

• add print group ("lp", in many cases) to the groups for users I want to have print access. Users who are not in lp or whatever, can notprint or cancel print jobs without rooting-up.
• decide which ppd to use with the printer.

With these two accomplished, try to add the printer:

# lpadmin -p HP1100 -E -v socket://192.168.1.101/printer -m hpijs.ppd

This may return the error that the hpijs ppd file, in this case hpijs.ppd, cannot be copied. Ppd's need to be in the correct format (uncompressed ppd) and directory (/usr/share/cups/model) if lpadmin is to find them and add them.

Foomatic hides and zips their ppds. I finally located them in /usr/share/cups/model/foomatic-ppds/HP. The one I needed was HP-LaserJet1100.ppd.gz. I copied this file into /usr/share/cups/model , unzipped it: "gzip -d HP*", and renamed it hp1100.ppd for ease of loading. Then I ran:

# lpadmin -p HP1100 -E -v socket://192.168.1.101/printer -m hp1100.ppd

The printer was successfully added to the system. Suppose, however, I wanted to try several .ppd files to determine the one with the clearest print and functionality? Ppd files can easily be added and deleted. Simply copy the new .ppd file (let's call this new one eg, another.ppd) into /usr/share/cups/model/ and run:

# lpadmin -p HP1100 -P another.ppd

What works: configuration

Ideally again, one should be able to use the CUPS webtool at  http://localhost:631 for configuration, just as we were supposed to be able to add printers with it. If the web interface is working, use it. If not part two of our work will be to modify the file /etc/cups/printers.conf with the right settings and restart the CUPS server so it reads the file. In /etc/cups/printers.conf one line has different possible structures depending on how the printer is attached. Let's say we've named our device "printername", some possibilities are:

DeviceURI socket://ip.address/printername #LAN
DeviceURI socket://ip.address:ps101name #LAN version2
DeviceURI parallel:/dev/lp0 #parallel port
DeviceURI usb:/dev/usb/lp0 #usb port

I experimented until I determined the correct one for the physical connection which, in my case, was on a LAN. I looked in my router and found my printserver received DHCP at 192.168.1.101.
I navigated there (http://192.168.1.101) in Firefox, and found a GUI interface which allowed me to rename the printserver to any name I desired, but decided to leave it PS101. Accordingly, the successful syntax for my DeviceURI was this one:

DeviceURI socket://192.168.1.101/PS101

and my final working configuration file went like this:

/etc/cups/printers.conf
# Printer configuration file for CUPS v1.3.7
# Written by cupsd on 2008-12-01 04:19
<DefaultPrinter HP1100>
Info HP1100
DeviceURI socket://192.168.1.101/PS101
State Idle
StateTime 1228132708
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

After all this, I ran

# service restart cups

in order for CUPS to re-read the /etc/cups/printers.conf file with the new information. I was able to print from all programs.

test prints

While testing printer ppd's, I ran a lot of test prints. Some worked, but the ones that didn't print piled-up in the queue, and the CUPS interface at http://localhost:631 would never allow me to delete jobs. CLI solution to delete print jobs, (assuming CUPS is running, there is no "lpstat" w/out CUPS):

# lpstat -o

provides pending print jobs and the job number eg, "HP1100-1". Then

# cancel HP1100-1

will get rid of the job. Run "lpstat -o" again to verify, if you like.

# lpstat -v [list of installed printers]
# lpstat -d [names default printer, also can specify using this]

xfce4 note

To print from Mousepad and others that use X-settings, xfce printing needs to recognize the CUPS printer. Try printing in Mousepad and see if the CUPS printer is available. If not, configuring xfce4 to CUPS will be necessary. This was simple for me. I simply went to the XFCE menu, then access Settings ->Settings Manager -> Printing System. Once in Printing System, I selected the CUPS network printer and closed the menu. I then opened a Mouspad file to print; sure enough, the CUPS printer appeared in my options.

What is supposed to work (as opposed to all of the above)

First, good CUPS documentation here.
Essentially, one should be able to navigate to CUPS at  http://localhost:631 with Firefox and add printers, manage the print queue, or do other config changes. I never could get the parts to sync enough to add a printer, let alone administer them. Some considerations:

• GUI authentication: CUPS apparently relies on PAM, Slackware does not provide PAM?
• parallel: HPLIP is supposedly needed for support if using a parallel port, but not for network printer. I could not get HPLIP to see the parallel port on the legacy system
• parallel: snmp might be a factor

In the name of gleaning understanding and advancing progress from previously attempted approaches or, at least, of not duplicating effort,here were some initial directions:
1. configure network and verify dhcp assigned print server and slackbox IP's. Let's call these IP's as follows:

192.168.1.101 - Print Server 192.168.1.102 - Slackbox

2. check /etc/rc.d/ - verify rc.cups (and rc.hplip, if it were needed) are 755.
3. is printer plugged in? PS101 plugged in?
4. Firefox to http://912.168.1.101. Blue admin page. Change or leave the name of the PS101, but be sure to write it down - you will need it later in your /etc/cups/printers.conf file. Print a test page to see that the server is talking to the printer properly.
5. Firefox to http://localhost:631 CUPS admin interface. Make sure it comes up.
6. Check that tcp and udp ports 161,162, and 9100 are not locked-down.

CUPS Webtool notes http://localhost:631

1. Try adding the printer with the CUPS webtool. It likely will wait until the (frustratingly) last step in the process and reject your password. Since CUPS uses PAM for password authentication and Slackware doesn't use PAM, I made many many many attempts at editing the /etc/cups/cupsd.conf file to eliminate the password requirement, but it always prompted me for a password in the CUPS webtool. According to the information at this slack site here is how one should proceed:
A. Lets say your name is "doofus" and you declared your SystemGroup in cupsd.conf as "wheel":

lppasswd -g wheel -a doofus

B. Check to be certain:

# cat /etc/cups/passwd.md5 doofus:wheel:01234567890abcde1234567890abcde12

C. Now restart CUPS and go back to the webtool in Firefox and add the printer:

#/etc/rc.d/rc.cups restart

I never got it to work; the password was always rejected and I could never add a printer.

SNMP HPLIP

SNMP (Simple Network Management Protocol) is a powerful process originally designed to simplify web management. Many processes take advantage of SNMP functionality and one of them is HPLIP

If hp-setup doesn't work, then the road may be long. Try using SNMP to determine if the kernel can see the printer at the nework address:

snmpwalk -Os -c public -v 1 ip.address.of.printer 1.3.6.1.4.1.11.2.3.9.1.1.7.0

Per this site HP tshoot, the response should be something which shows the manufacturer,or SNMP may not be installed correctly. This means working with the /etc/snmp/snmpd.conf file.