Measure twice, cut once – That is an adage that is familiar to many IT professionals that are responsible for deploying software that affects network infrastructure and user policies. Thorough testing of an application prior to deployment can be a crucial factor in the overall success of a project. In some cases license restrictions can limit the ability to test an application completely, but that’s not a problem with PaperCut. Our license is designed to allow you to test every aspect of our print control software prior to implementation.

Anyone wishing to conduct performance, functionality or “what if” testing can download the latest version from the PaperCut download page. This is the same version of PaperCut that is used by over 30,000 sites worldwide when they upgrade to the current version. At the end of the 40 day trial period you will be prompted for a license key when you open the PaperCut Admin Console. The printing managed by PaperCut will continue to work just as it did during the trial period, however many of the PaperCut administrative and print reporting capabilities will be disabled until a valid license key is entered.

The trial version is primarily used by prospective customers to evaluate PaperCut, but some sites go into production during the trial. I know this because one of the questions that I am asked most frequently is if the configuration and print log data from the trial will be retained in the permanent version. I love hearing that sigh of relief when I tell someone that it only takes about 10 seconds to register the license and they will be off and running with everything intact! Some folks wait until after the trial license has expired before they contact us. No problem, PaperCut keeps tracking after the 40 day license has expired and all of the information will be current when the license key is entered.

Sites that have purchased PaperCut do not need to buy an additional license for testing. A test server can be set up with either the trial license or the purchased license. Uses include testing with different operating systems, new versions of PaperCut and new network configurations. In addition, the purchased license can be installed on multiple servers during a server migration. This eliminates the need to uninstall or decommission the previous PaperCut installation before activating the new server.

If you need additional time to test or evaluate PaperCut, or if you have a situation that requires additional flexibility in order to be fully tested in your environment, please contact support and we will issue you an extension license that will allow you to complete your testing.

Image “Measuring Up” by lowjumpingfrog / CC BY

Ah … my tax time again! What a complicated mess that is! “Enjoyment” only matched by one thing: Managing web server SSL certificates and dealing with the corresponding certificate authorities!

As PaperCut system administrators like Geoff from Colorado, John from Illinois or Robert from Iowa have recently found, managing SSL certificates can end up making doing your taxes look fun. This is in no small part due to the bureaucratic nature of the so-called X.509 and PKCS standards, which are as onerous as their names make them sound! Further more, it’s exacerbated by the shenanigans of “certificate authorities” – those self-proclaimed guardians of Internet security that have somehow conspired with Microsoft and Mozilla to create a protection racket that charges each web master hundreds of dollars* for their web site to come up “green”… for a year only… then rinse, and repeat.

Not befitting its central role in The Grand Scheme of All Things Internet, the list of 20 or so certificate authorities dividing this booty remain sheepishly hidden in the deeper folds of Windows under
Control Panel -> Internet Properties -> Content -> Certificates -> Trusted Root Certification Authorities.
System administrators wanting to provide validated HTTPS access to PaperCut’s end-user web pages (where users can perform various print management tasks) will have to create an SSL key for their domain. This key must be signed by one of these authorities.

The instructions in PaperCut’s manual on how to import SSL certificates trying to be as general as possible to accommodate all certificate authorities. However that doesn’t prevent some of them from making system administrators’ lives extra difficult by inflicting distractions such as:

Expired/changed root certificates: A certificate authority’s root certificate is normally created once and maintained for ‘life’ – where ‘life’ means ‘decades’ – certainly a long time on the Internet. This justifies the arduous process of distributing it to all operating systems, browsers, mobile devices etc. in the first place and ensures its integrity through broad public availability. Some authorities have nonetheless taken to signing customers’ keys with new root certificates long before the old established ones had expired.

Being a cross-platform solution, PaperCut maintains a list of root certificates independently of the operating system. These certificates are used to ensure integrity of the certificate chain. A new root certificates may or may not have reached wide circulation and in particular, may or may have not made it into PaperCut’s list. In case it didn’t, it is the system administrator’s responsibility to obtain the new root certificate from the authority and install it with the help of the command line provided in the manual.

Intermediate certificates: As an additional layer of bureaucracy, some certificate authorities sign customers’ keys with an intermediate certificate which in turn is signed with the root certificate. These intermediate certificate usually have shorter life times than root certificates, exist in larger numbers – several per authority – and although also mandated to be present in PaperCut’s list are less likely to be included in it to begin with. If an intermediate certificate has been used, it must also be installed as above.

Other formats: Like a siren luring the errant wanderer into the treacherous swamps of eternal doom the certificate authority might tempt the customer with certificates presented in ‘additional’ formats like PKCS#7. PKCS#7 promises to simplify the certificate import process by bundling the customer’s certificate with intermediate certificates which can be imported in one go. This may or may not work, but one thing’s for sure, it’s one more condition to lead to more confusion!

At this point the inclined system administrator may start to question the logic behind all this. My advice in the interest of avoiding a headache and maintaining overall health and sanity is: Don’t! As with all thing imposed on one from above, be it taxes or X.509, the best thing one can do is smile and play along.

Whew! Now back to those taxes …

Lock and chain image from Bala on Flickr / CC-BY-SA

Is it a coincidence that PaperCut currently supports 42 printer description languages , that I am turning 42 years old this year and, as we all know, 42 is the Answer to the Life, the Universe and Everything? Yeah, it probably is

Since joining the PaperCut team, I have mainly been working on the area of PaperCut responsible for the analysis of print jobs. I have come from a background of programming in the computer language, C, doing file system programming in the Linux kernel. I worked for SGI on the XFS file system team. The job analysis code in PaperCut is entirely written in C which has given me a chance to sink my teeth into something quickly. Luckily for me it is also well written C code and has been designed to be easily extended for new print languages and print drivers.  Every few weeks printer manufactures release new print drivers and these need to be tested with PaperCut.  Changes are always occurring.  Sometimes these changes are minor and just a little bit of tweaking is required, while others are a lot more complex. In some cases we need to support whole new print languages.

Many of the lower cost printers these days are using GDI drivers.  These are drivers that don’t support known popular standards like PCL or PostScript and implement their own protocols – often not documented nor following any existing standard. In order to handle new GDI printer languages, it’s a bit like playing a game of detectives. By reverse engineering, we try out various sample documents, changing different page attributes and work out how the driver encodes the various attributes (e.g. duplex, gray-scale and paper-size). We have a set of pattern tools and a few techniques that help us perform this decoding process.  After a bit of teeth pulling we develop an algorithm to support the new driver.  The techniques are in some ways similar to those implied in reverse engineering file system formats!

After we’ve made changes to our print analysis code, we run our analyzer tool over a corpus of over thousands of real-world documents to ensure we haven’t introduced any regressions (steps backward).  The tools also check for memory leaks and test performance against previous test runs to make sure the software is not getting slower.

I hope you’ve enjoyed the behind the scenes look into some of the technical workings here at PaperCut. For a less technical look, make sure you check out what print management has to do with Coffee?

42 Image from Answer To Life / CC-BY-SA