atp

This should be a simple enough job - after all 'it works on ubuntu out of the box' (tm).  Take the USB printer and move it onto the home server running Centos 5.9, so that I can share it with the mrs' macbook and my desktop/laptops etc.

Here's the hurdles encountered and the fixes, so my future self won't have to waste time on this again.

First problem. On Centos, the printer - an Epson SX218 inkjet printer is not recognised. So no problem, off to open printing to get the driver; http://www.openprinting.org/driver/epson-escpr/ which points me at epson's website. A bit of javascript later and I've got my hands on 

epson-inkjet-printer-escpr-1.2.3-1lsb3.2.x86_64.rpm

which yum localinstalls fine with a few dependencies (after ignoring its gpgcheck).

Setting this up with system-config-printer now proves easy. Except that when we get to test print it just sits there like a lemon not doing anything.

Some more digging gives this in the /var/log/cups/error_log;

E [01/Sep/2013:12:44:05 +0100] PID 3772 \
     (/opt/epson-inkjet-printer-escpr/cups/lib/filter/epson-escpr-wrapper)\
   stopped with status 13!
I [01/Sep/2013:12:44:05 +0100] Hint: Try setting the LogLevel to "debug" to find\
   out more.
E [01/Sep/2013:12:44:07 +0100] [Job 122] Job stopped due to filter errors.

(lines wrapped for readability)

And in https://localhost:631 (once I'd added the rngd -r /dev/urandom hack and run find enough for it to generate enough entropy to generate a SSL cert) it tells me that 

/opt/epson-inkjet-printer-escpr/cups/lib/filter/epson-escpr-wrapper failed

At this point I forgot about golden rule number 1. Read the error message. Error 13 is a file permissions problem.

Google was no help - or my google-fu was lacking. There's plenty of complaints but no hint as to the real culprit for centos 5.  The Arch and Gentoo guys recompile from source and all is ok. Others do various sorts of things, and most seem to find something in gutenprint/gnome-print that does the job for them. Unfortunately my SX-218 isn't listed in the list of printers supported out of the box. I could try something generic, but it's annoying this isn't working. So a matter of honour now.  

After about an hour's wasted thrashing around, I finally cottoned onto the error message, and checked the usual. Since the binary links ok and has no missing libraries, and has permissions of 755, the culprit has to be selinux. 

Sure enough, everything worked with setenforce 0. 

To make it work with setenforce 1 - i.e. enforcing selinux - the next step is to create a local policy. 

The simplest path forward was to use audit2allow

audit2allow -a -M cups
******************** IMPORTANT ***********************
To make this policy package active, execute: 
semodule -i cups.pp

 Which creates a cups module. The .pp file is the binary module to load with the indicated command, and there's also a .te file which holds the text rules. 

The important section is;

#============= cupsd_t ==============
allow cupsd_t lib_t:file execute_no_trans;

After the module is loaded, selinux back on, and cups restarted all magically works. 

The mac now prints remotely, and all I have to do is fix the ubuntu desktop, which is running 10.04. 

Onto problem 2. 

The queue is found, and everything seems ok, but print jobs just sit there in the queue. Eventually they time out, and tell me in the error log on the desktop that;

[Job 569] Print file was not accepted (Unsupported format 'application/octet-stream'!)!

Luckily this time google comes to the rescue. The problem is that the server is not accepting the raw stream of data from the desktop. 

All the way back from December 2001... 

http://lists.samba.org/archive/samba/2001-December/034301.html

Advises me to edit /etc/cups/mime.convs and check the application/octet-stream line is uncommented.

# Raw filter...
# Uncomment the following filter to allow printing of arbitrary files
# without the -oraw option.
#application/octet-stream application/vnd.cups-raw 0 -

So, removing the '#' from the start of that line, and another service cups restart sees me home to a working print server. 

Seriously though, I know centos 5.x is old, but help from 2001? Thats two thirds of the way back to the time when I was installing 1.0.9 on a 386 and OSF 1.2 on an Alpha Sandpiper.