This is the first part of a series explaining how to use TTP iPrint Printer Lists. These lists are designed to make iPrint easier in a complex multi-site OES environment. These articles will not only explain how to set them up, but will also use this project as an example of a way that OES can be extended within an organization to meet new needs.

The files for setting up printer lists will be included with the last of these articles.

This solution was developed for a member institution of the Technology Transfer Partners (the TTP). The TTP is a group of like-minded computing technical staff from academic sites around the world who discuss the issues that are facing them on a day to day basis and look for support from their colleagues. Membership is free and includes numerous benefits.

Why Do We Need Printer Lists? The Perils of Large Environments and Consolidation

Traditionally, Novell (now Micro Focus) solutions have excelled within large, complex organizations because they are highly scalable and provide a means to handle unusual relationships between different levels and divisions of an organization. For example, my own organization (the School District of Escambia County) has roughly sixty different schools and a smattering of administrative centers. We would like to be able to manage printing centrally as well as delegating authority to technology coordinators at individual schools. Some of those technology coordinators serve more than one site, so the ability to be very specific about rights across a particular level of the organization is very important. Moreover, we have a very mobile workforce and studentry where some students may move to a different school several times during the course of a school year.

iPrint on OES serves this use case very well. We can have multiple print managers serving different printers but still be able to access all of these managers from one administration tool (iManager); use a common, dynamic set of users; and easily handle rights between different managers and locations. Since iPrint is quite efficient in its job handling and we have a strong network backbone, we can also consolidate multiple locations into a single print manager rather than having a separate print manager at each site. In short, we can deploy six print managers that can be centrally managed to serve ten times that many schools.

Similar functionality is not currently available in the iPrint appliance. Each appliance is currently an island, except for the ability to use a common Driver Store. The iPrint team has indicated that similar functionality is part of their long-term plan, but I would not expect to see a version of the appliance that can link to other appliances in the near future. The current situation means that we have an unfortunate choice: We can either have central management and scalability for large organizations (OES) or we can have the latest feature set and newer management interface (appliance) but we cannot have both in early 2017. As my organization does not currently license the mobile piece of iPrint, it is easier for us to hold off for a while and stay on the OES version while waiting for later iterations of iPrint that may improve the feature set.

There is one further problem with consolidating multiple sites onto a single iPrint Manager: The list of printers available gets too long for users to easily install them via the built-in self-service website. If you go to http://yourserver.com/ipp after adding forty or so printers to the manager then the problem should be apparent -- the list of printers to select from is too long. Even worse, you may not have been able to enforce a sensible printer naming convention or users may misread printer names. That is, a user might install the wrong printer because the model or location or name looks similar to the one nearby (this can easily happen if printers are named by room number but not building, for example). The result is users who submit jobs that don't seem to print and other users who are very annoyed when print jobs from a completely different place (perhaps miles away) suddenly start appearing on their printers. Phantom Printing is suddenly a serious problem.

Possible Solutions

The iPrint engineers have considered this sort of use case since the very birth of iPrint on Netware, and three possible solutions present themselves in an OES environment. We can control printer installations via ZENworks printer policies or iPrint Client Management (iCM), we can use a printer map for users to install their printers, or we can maintain a static webpage for each group of users that only includes a small subset of the printers available on the manager. Let us consider each of these methods in the context of their suitability for our current use case: Multi-site print managers and multiple print managers with users self-servicing their print needs.

Both iCM and ZENworks printer policies are great ways for an administrator to push printers down to a workstation. I tend to prefer ZENworks over iCM because iCM has performance problems when the source eDirectory server does not have all partitions, and can sometimes be difficult to administer when dealing with groups and multiple layers of the eDirectory hierarchy. ZENworks, by contrast, has a lot of neat tweaks in its printer policies including automatic client installation, updating and forced-installing of drivers, handling of non-iPrint printers, and much more. ZENworks is also a little more current than iCM as the latter feature was originally created to replace a feature of NDPS printing and has not been iterated and improved over time as much as the ZENworks product. But you have to license ZENworks to use these features -- They are not included with OES alone.

Both iCM and ZENworks printer policies have two great flaws that remove them from our consideration. First, they are both Windows-only which is a disqualifying factor in a mixed educational environment (i.e. one with Macs and Linux clients). For many sites this is not an issue, but it is in ours. The second defect is foundational: These technologies are both means of pushing printers to users and workstations, but we want our users to have convenient self-service access. If we control which printers are installed then we must take responsibility for knowing which printers they will need at a given moment. Such solutions have a place in our iPrint deployment, but they should be secondary to empowering the users.

That brings us to the famous iPrint printer map. When iPrint first debuted the ability to place printers on a map of your building was a novel and exciting feature, touted in training and documentation. Unfortunately, over time the interface to this feature has started to show its age both in its implementation (placing printers can be fiddly and unreliable during creation) and look-and-feel (the icons are looking very Web 1.0). A larger concern lies with user capability: We have found that a significant portion of the user population cannot find their own room on a map. Separate from the printing issues, this discovery has grim implications for evacuations during a fire evacuation. It also means that users are unlikely to be able to determine which printers on the map correspond to physical printers near to them.

The simplest solution among our choices is to create a series of webpages very similar to that displayed via the "/ipp" URL but with a smaller set of the printers. The OES iPrint documentation describes how to create such a page and even offers some sample HTML to help the reader along. At the time of this writing, it can be found in the OES documentation under "OES 2015sp1: iPrint Linux Administration Guide"->"Customizing iPrint"->"Customizing the iPrint HTML Interface". The iPrint team is really trying to make sure that administrators have a wide toolset available to them, and so our eventual solution will leverage the capabilities that they have already given us here quite heavily.

The Shape of Our Solution

The iPrint HTML page examples require creating a separate web page for each group of printers, and to directly edit the HTML web pages every time a printer is added or deleted. Such a page would be much more useful if the list of printers were generated dynamically by user group, or location, or any other criteria an organization can imagine.

So that is exactly what we are going to do.

The end result of our initial solution will be a web page where users can go to and see a short list of printers that are relevant to them. They can see basic information about these printers and click a link to install a given printer using iPrint. For administrators, it should be very simple to set up new webpages that will display these lists of printers and it should be even simpler to make changes once the page is set up. The setup should leverage existing, stable technology when possible with simplicity so that it will not inadvertently create new problems. TTP iPrint Printer Lists provide this solution with those requirements.

This use case is the initial reason that TTP iPrint Printer Lists were developed. However, as we continue this series of articles we will discover that our work can be repurposed.

Technologies

The standard approach when writing an application like this is to require a brand new database, preferably either a very common or new and trendy one, to hold all of our data. Sadly, even some on the iPrint team have fallen into this trap. It is an age-old temptation as the Great Jamie Zawinski discovered when a new team took over his work on Netscape's mail reader.. The general expectation from programmers seems to be that sysadmins will breezily consent to administering a brand new database and that this new database will not conflict with anything else on the system or consume additional time and resources.

As I came into programming by way of systems administration, I have no such illusions. Setting up a new database requires planning and adds overhead to backups and security planning. Moreover most SQL databases are relatively fragile and any problems with them generally lead to having to restore from backup since any corrupted data leads to the expectation that no data can be trusted.

Fortunately there is already a great datastore available to us, one that is already running on OES and even used by iPrint itself. I am, of course, talking about eDirectory. We know that eDirectory can be the foundation for very scalable and complicated applications (ZENworks 7 and previous come to mind), so it will surely suffice for our tiny web app. Moreover, the iPrint printers are already defined within it. Even better, it uses LDAP for communication which is intrinsically more secure than SQL because it does not communicate in-band. It is substantially harder to attack LDAP via injection. Most programming languages have a decent LDAP library, so it also opens up some possibilities there.

TTP iPrint Printer Lists are not especially complicated, so we do not need a heavy programming language. It should be capable of displaying websites, have a good LDAP library, not require much administration, support fairly quick development. With all these requirements in mind, I chose PHP. It is included with OES via SUSE Linux Enterprise Server, has very good support for LDAP, and outputs directly to the Apache web server. It is not ideal for all projects, but it is for this one.

Finally, we need an administrative tool. While we could build one in PHP, eDirectory already gives us a perfectly fine tool with iManager.

In Part II we will look at how we can use eDirectory to create our printer lists.