The "day of the week" puzzle
We have recently seen reports from clients which state that RPM stops processing jobs on a specific day of the week. The baffling thing is that if there were a date-sensitive problem in RPM, it would show up for more than a handful of clients. While it wasn't the same day for all clients, the stoppage tended to cluster on Mondays and Fridays.
We believe we may have found the problem! It seems to be related to network scanners, such as Nessus and OpenVAS, among others. We are sure these are excellent products for their intended use. They probably don't intend to interfere with a software print server product.
What we've done to address the scanner problem
In a previous article, we showed how specific scanners caused RPM to create non-existent queues, merely from the action of the probe. These unexpected queues caused some anxiety for several customers since they didn't know why they were appearing. If there were hackers, the customer wanted to know.
Here is an image of the unexpected queues:
We proposed in the article that you turn OFF automatic queue creation. Usually, it's handy for RPM to create queues from upstream print requests. You can open up a new print-stream and send it to RPM, without configuring RPM first. An admin might generate jobs in a new queue for RPM. In turn, RPM holds on to the jobs until you have created a queue setup for handling those jobs.
However, that convenience disappears when the admin is removing "junk" queues. We realize this is a trade-off, RPM's creating new queues versus the inconvenience of new queues "magically" appearing.
Mysterious input
The customer who contacted us most recently had a more severe problem than odd queue names appearing. It seems that in recent months, people report RPM stopping altogether.
The customer was able to provide us with a diagnostic log. They also turned on "capture" in the LPD protocol handler, which generates capture files in the RPM "JOBS" directory. These tools worked together to provide us the clues we needed! Now, we were getting scanner input that was close enough to an LPD request to work, but too far from LPD to work correctly. RPM was starting to generate database errors. We believe that the halt to processing comes from this.
With capture files from the customer's machine, we were able to reproduce the customer's problems. And we were able to do so without violating data privacy. The capture files have only metadata, no print data.
Adding data anti-bodies
The biggest problem in sorting out LPD commands is that in many countries, a legitimate queue name contains more than just ASCII characters. Beyond that, queue names might easily be in the local character set and not Unicode. Unfortunately, it's impossible to scan the command for strict compliance with a standard that does not exist. Not when it comes to which characters go into names.
However, we had a plan. We added logic to determine whether the LPD command layout follows the reference description in RFC 1179, the LPD reference document. In effect, we've introduced an antibody that says, "you started out looking good, and now I will make sure you look good until the end."
Results
So far, our results have been excellent. Each time a network scanner sends "probe data," RPM generates a Critical Event (which warns the user when the UI is open) and generates a message in the event log.
RPM itself continues, unphased by what is happening.
Conclusion
- RPM is a print server. We can't support the product in a hostile environment where the software can't do its job.
- We will do our best to work around issues such as the scanners, but ultimately, if RPM doesn't work with your scanner, please consider stopping the RPM service while the scan is running.
- alternatively, please select "lpd2" in the diagnostic logging, and turn "capture" on for LPD