Anyway, I figured I might as well move the entire thing to an open CMS project that I’ve heard some good things about and already implements everything and more that the customer could ever want. That’s CmsMadeSimple.

Converting the old website to the new one was trivially easy. Copy/paste the stylesheet (first mistake), edit the basic template with a menu section, create the pages (copy/paste, copy/paste).
After fixing the html errors that were in the source the page looked like a pixel-perfect copy of the original.
Except for the places where the HTML errors were fixed that is. (the center class now actually worked for instance)

However, when adding the print links I ran into an interesting issue.
Adding print links is also a trivial thing, simply put {print} somewhere in the template, and possibly add some options to show an image instead of a text link etc.
However, the links were kinda broken, they gave empty pages. So I figured “duh, the print template still needs to be fixed”. However, as soon as I added the {content} tag to the template, I got a nice internal server error. WTF.

Checking the logs I could only find nice reports of this:

Well… .I expect nothing less from php. Pleuris-hoere-product. But how the heck… just because I added content to the print page? What’s so special about that?

After digging around (enabling logs etc) and enabling fopen for php (which I had disabled for security), I noticed this:

AHA!. Apparently the printing module fetches the content (or at least, tries to) from the webserver, fails, and then segfaults php. Excellent code guys!
The reason for the failing is obvious from the logs here, I require authentication for the website since this is a test location that shouldn’t be public. Quick fix, allow the server to skip the login (vhost config):

Problem solved. (Hint Printing Module: render your own shit, don’t cheat with fopen/curl)

Oh yeah: CmsMadeSimple rocks for these simple websites where your customer wants to “change some texts and add a picture”. If they can handle word, you can make them handle this (but show them how!).
Give them permissions to add pages and nothing else, write a decent template for them, done.

So we fire up xpdf on the document, hit the print icon, lpr, GO!
*time passes*
Mhm, what is it now?
*check http://localhost:631*
Nope, no document there, seems like it was handled by the printer.
*check cups error_log*
Heaps of garbage there.

Remember that we had this issue left in our previous cups story? Something about PDF printing causing issues?
Well, since then cups got upgraded to version 1.3.11 and some other stuff too, like ghostscript.
This time the error log showed something like this (only the relevant part here):

Some weird definition of ‘successfully’ you have there, cups.
After a few hours of debugging through that error_log, fucking with filters in /usr/share/cups/filters (cursing at Brother for their half baked wrapper scripts), turning on and off debug and log options
I was getting more and more annoyed with it. Considering on how to pick up the Brother DCP-135C and smashing it through the 2nd story window onto the pavement, but then not being
sure if it really was the brother’s fault at all, I decided to make sure once and for all which one I had to throw through the window.

Time for a manual debug session with the filters again. If you are having trouble with stuff like this, I can commend it to you. The steps I took (after the usual turning on debug and log options etc):

1. Grab your input file, in my case some PDF document which I ran through xpdf.
2. Instead of sending it to the printer, print using the “save to file” option so we have the source that cups has to deal with to work with.
3. Manually run this file through the filters as cups does. I curse on cups for not being more specific — EVEN WITH THE LogLevel debug2 OPTION TURNED ON (it just becomes MORE unreadable, but without more information) — about how it runs these filters, but there are some shell scripts floating around that you can use. What I did was just use
   strace -qfve execve -p `pidof cupsd` -s 250

   to figure out how my filters were called, but be ready to read tons of output on that one
   Anyhow, to save you some trouble, the call syntax seems to be

   filterprogram PRINTER JobNum User title copies documentoptions [file]

   or a real example from my test case:

   /usr/lib/cups/filter/pstops "DCP135C" 666 benv jemoeder 1 "document-name=4a93e8d852a17 number-up=1 job-uuid=urn:uuid:873e2907-cf50-35e2-5626-741377b394be" "/var/spool/cups/d00666-001"
4. Find out which part fails. The pstops had some output that looked fine by me, as far as I can read postscript as it scrolls through my terminal.

Funny thing is…. it seemed to me like pstops worked fine, as did the brother cups wrapper….
However, there was still this soab left:

Execution of /usr/bin/gs showed up in strace as well btw, don’t worry
So now the big question was: when did ghostscript become retarded?

I took my “print to file” postscript document, and tried opening it in ghostview.
It just looked at me like a cow looks at an oncoming train. Or in its own words:

Ah-HA!

….

What?

Since I’m by no means an expert on postscript, I googled it. The search revealed that apparently this could be the result of an eps image conversion gone bad.
Postscript doesn’t like to deal with binary data, so it’s not supposed to be there.
This can mean only one thing!
xpdf failed!!!!!!

Some testing revealed that xpdf on the old slackware32 chroot environment still does work, and printing the exact same PDF file there works fine, while printing that document from the 64 bit
slackware envrionment fails with the above story. Fascinating. Seems like it isn’t a library issue though, unless it’s cleverly hidden in the X libraries. I hope they’ll fix this soon
Just for reference, this is the xpdf-3.02pl3-x86_64-1 package that fails.

Well, now that we all know the details we can go to bed.
And if you need to print that pdf document: simply use pdf2ps, it works. (and stay away from habbokrat reader)

Attempt 1:

Easy. It even works, the printer starts rumbling and out it comes. Oh…. seems like the barcode is a bit screwed…. mhm, wonder how it managed to do that. (the rest looked fine).
Browsing through the cups error_log gave some gibberish, this line caught my attention:

Mhm, interesting. Google returned a bunch of filter thingies, and I was like “maybe it’ll work better if I try converting it to ps myself first”.
So I ran pdf2ps (instead of pdftops as cups does) and viewed the resulting ps file. Looks a lot better. Print it!
lpr on the file, and out it comes. Huh, no landscape? I try lpr -o landscape stupidfile.ps which also does portrait. RAAAH, STUPID KANKER CUPS.
After an hour of google and cursing I said “Fine, you do it” to lotjuh, who asked me earlier if she had to do it with her Habbokrat Reader…. what a piece of garbage that is….

Anyway, lotjuh soon ran into a new issue. First of all, her new Windows 7 didn’t have a printer driver, and trying to install the Vista on failed. Our printer is a cheap Brother DCP135C, which isn’t THAT old I thought. Oh well, that’s your windows problems for you
So she booted to linux. Surprise! Print didn’t work. That is, it said “OK” but out came nothing. Jobs just collected at her local cups.

*grumble*WHYYYYY???

Debugging this is a tough, since none of the logs give any useful information whatsoever, even in debug mode.

To understand this problem you might want some more network background info:
We have our internet through xs4all, who gave us a Fritzbox for that. Since I couldn’t get it to work like our previous internet setup with the external IP address on our local server,
we eventually decided that the thing could route for us, but we have our own DHCP server running on our local server.
So in our LAN the default gateway is the fritzbox, but our local server has most ports forwarded to it. In order to also run a dns server and dns cache it has multiple IP addresses in our local lan.
In fact, it has 3 IPs in the 192.168.1.x range on a single ethernet device.

Back to cups:
In cupsd.conf I have Listen 192.168.1.1:631. That should work, right?
However, BrowseAddress only accepts a .255 at the end, or an @IF statement. So I had @IF(eth_local) there.
Result: clients get confused, try to send data to all 3 IP addresses on the network. And since I can’t put the primary IP address in the BrowseAddress…. it fails.
My guess is that cups detects all 3 IP addresses on that interface and happily announces those, while only 1 of them should be used. Especially because of the listen statement.
I fixed this by using the second address, which I conviently have on a ‘different’ ethernet device eth_local:0. This seems to work a lot better, the clients now have a single printer in their cups
configuration and it even provides its location!

instead of the old

However, my first problem was still present. The whining about invalid PDF files. Printing from KWord also gave this error. The local cups would happily forward my job to our server, which then barfed on the thing:

… well, that’s just lovely.
(insert your curse of the day here).

Oh btw, if anyone ever wonders about the status of their printer and cups and everything:

So far I haven’t found a solution for this problem yet, except for a print to file, scp, manually convert, lpr style workaround, but that’s tedious.
If anyone knows, I’m interested in the cause and fix for it.