Finally, End User Functionality

Part I is here.

Part II is here

Part III is here

Part IV is here

I hope that dealing with iManager was not too much of a slog. We have finished with our data store (eDirectory) and our management interface (iManager)– from this point we get to the fun stuff: Enabling our users to get their printers with printer lists.

In this article we are going to discuss the underpinnings of our end-user services. Subsequent articles will document how to use the base printer list functionality and then we will conclude the series with extended functionality.

A Note About the new “iPrint for OES” Product

I have been evangelizing iPrint printer lists within my organization and within the TTP membership since 2014. I have also been asking the iPrint team for supported functionality along these lines within Open Enterprise Server (OES) since the iPrint appliance was released pre–2014. For a variety of reasons the iPrint appliance does not meet the needs of my organization.

The iPrint team has now responded to many, many customer requests (including mine) by essentially porting the iPrint appliance back to OES. This is the new product that was released in May 2017 called “iPrint for OES” and which will also be in OES 2018. This add-on is an initiative led by the iPrint team, which is separate from the core OES team.

There are four very important things to know about “iPrint for OES”:

1. 1. It adds a lot of new functionality including support for mobile devices (additional license) and Chromebooks (included with the standard Desktop license bundled with OES). Searching and listing of printers similar to TTP iPrint Printer Lists is part of the new feature set.

1. 1. The “Classic” iPrint functionality that OES had prior to OES 2015sp1 still exists and is shipped with OES 2015Sp1 – not with the add-on iso. “Classic” iPrint and “New” iPrint are essentially sitting side-by-side and do not interact much. They have separate entries in the OES documentation set.

1. 1. The “New” iPrint in “iPrint for OES” takes a very different approach than the one I have outlined in this series. It has its own administrative interface distinct from any other tool in OES and uses its own database separate from eDirectory to store information that is not part of “Classic” iPrint (such as printer groupings). Note that it is not entirely separate from the existing iPrint product – it uses the existing pieces as they are, but does not extend them for its new functionality. The iPrint team is full of skilled developers who are great people, but they have a very different philosophy regarding OES development than I do.

1. 1. You can deploy TTP iPrint Printer Lists and “iPrint for OES” in the same environment and they will neither interact with nor hurt each other. Since my organization needs Chromebook support, we will definitely be deploying the new product. However, that does not mean that the printer lists described here are obsolete (as you will see when we start using them with ZENworks in a future article). They are different means to different sets of functionality, parts of which overlap in their purpose.

As of this writing, the documentation for “iPrint for OES” is here

iPrint Printer Lists Leverage “Classic” iPrint

At the start of this series I bemoaned the fact that iPrint Printer Maps were a cool feature that is underused. It is clear from the “Customizing iPrint” section in the “Classic” iPrint documentation that the NetWare and OES teams who pioneered iPrint had great ambitions for customers to leverage and extend iPrint in their environment. They presented sysadmins with very powerful building blocks which they could use to build their own solutions through iPrint.

TTP iPrint Printer Lists simply take the static examples given in the “Customizing iPrint” documentation and automate them.

If you go to the standard printer listing page on any OES iPrint server at http://servername/ipp you will see a three-column list of every printer on that particular server’s print manager. In the first column is the printer name, with a link that will install the printer on the local machine when clicked. The second column is the printer location. The third column is an “i” symbol that when clicked will bring up a pop-up window detailing end-user information about the printer.

There are two problems with this page. First, it shows every printer on the server regardless of whether the user really needs to see them all. Second, prior to OES 2015sp1 the page layout was a beige monstrosity from the 1990s. Our printer lists will resolve both these problems (although the second is also resolved by upgrading OES and bringing in the soothing Micro Focus powder blue branding). In doing so we will make use of all the elements that the /ipp page has already given us – the link to install, the pop-up information page, the various printer details, and even some static assets like the printer symbol.

(Intriguingly, the printer symbol is a gif on OES 11 and a png on OES 2015, but the gif still ships with OES 2015 even though it is not immediately obvious where it is used.)

Our Base: PHP and LDAP

The system requirements for TTP iPrint Printer List web functionality are simple:

1. 1. You must have iPrint installed and running on an OES server.

1. 1. There must be a web server running the Apache Web Server with PHP.

1. 1. The PHP LDAP extension must be installed on the web server and eDirectory must be accessible via LDAP.

It is possible to use separate servers for iPrint, eDirectory, and the Apache Web Server running PHP. However, if all of those services can be on the same server, so much the better. In fact, if you already have iPrint running on OES then all the components except for PHP will be installed and running by default. Adding PHP with the LDAP extension is just a few clicks in YaST at that point.

The reason for these dependencies should be obvious. We are going to leverage the web pieces of iPrint that already exist. Our iPrint printer objects and any eDirectory objects associated with them (including users, groups, OUs, printers, and by indirect association print managers) will be read and retrieved from eDirectory through LDAP. The programming logic and web page creation will be handled by PHP.

PHP is a problematic language, but if you need to do a sysadmin-y task and display it quickly as a webpage, it cannot be beat.

The Basic Procedure

In the next article I will describe how to set up and use the printer list webpages. For the remainder of this one I will describe some overarching principles of those pages.

For everything that happens from this point onwards we will be working through some variation of the following procedure.

1. 1. A user will by some means (here there be hand-waving) request a specific printer list or a series of printer lists. The DN of each printer list will somehow be included with the request.

1. 1. eDirectory will be queried for each printer list by DN.

1. 1. For each printer list we will retrieved title, description, and ttpiPrintMemberPrinter (multiple entries in DN format) attributes.

1. 1. Note that we do not retrieve the “membership” attribute of the printer list – we will generally already have used that attribute in step one (“hand waving”). See below.

1. 1. We will display the title and description for the printer list on the web page for the user to see.

1. 1. Then for each DN of an iPrint printer object in the ttpiPrintMemberPrinter attribute set, we will retrieve the location, description, and ipp URI for the printer.

1. 1. The printers will be displayed on the web page in rows beneath their list with their CN (grabbed from DN) as name, location, description, and a link (partially constructed from their ipp URI in the format given via the /ipp page) to install them on the local client.

1. 1. Repeat 3–7 for each printer list.

These steps form the core of what is a fairly versatile approach.

Printer List Web Page Modes

For our basic printer list page we will have four modes of deciding which printer lists to display. Each mode builds on the one before.

printerlist
Using this mode requires that we provide an array containing the DNs of at least one printer list object. When the PHP page is loaded, it will display all of the printers that belong to these printer lists.

objectstatic
The webpage will specify the DN of a user, group, or container that might belong to one or more printer lists. The PHP code will search via LDAP for printer lists that this object belongs to and will then display them using logic similar to the “printerlist” mode above. If the inheritance flag in the PHP page is set to true, it will also search for printer lists containing any groups and contexts (and the full context lists of those contexts) that the object belongs to.

objectdynamic
Similar to “objectstatic” except that instead of setting the DN statically, the DN of the object should be sent to the PHP page via a standard web form. Useful if you want to present the user with a range of possible lists and have them select the one they want.

userauth
Similar to “objectdynamic” above except that the object to be searched will be found by authenticating a username and password sent by web form post. Upon receiving these credentials, the PHP code will attempt to find the user’s DN and authenticate via LDAP. If authentication is successful, the PHP code will then use the user’s DN as an “objectdynamic” to find printer lists.

These modes are the ways in which printer lists are requested in Step 1 of our basic procedure above.

Web Page Construction

It is possible to build a fairly robust and complex application from everything we have already established. But it is my desire that printer lists be as simple as they possibly can be. Therefore I decided that only two files should be required to set up printer lists on the web server.

The first file is a simple CSS style sheet that will define the look of the printer list pages. It is separate from the program logic so that a single style sheet can be re-used by multiple printer lists. Customizing the look of the lists for your organization is as simple as modifying this file.

The second file is a PHP file containing all the programming logic, HTML, programmatic customization (via PHP variables) and documentation (via code comments) for the basic printer list functionality. Using a single file is a bit controversial, but I have good reasons for it.

The biggest reason is that to set up a second set of printer lists, all one has to do is copy the file to a second with a new name and change the customization variables. For example, you could have a separate page for each floor of your office building and give them names like “floor1.php”, “floor2.php” and so on. These pages could in turn be linked by another simple page that was just a list of links to the floor pages. Each floor page could be configured using the “printerlist” mode above to display a printer list for that particular floor. Once these pages are in place, admins would only have to add and remove printers from the various floors’ printer list objects and users would see the changes automatically when they visited the webpage for that floor. All of these pages could use the same, single CSS file.

Obviously, you could do the same with departments, buildings, and so on.

Even though users would see all the printers in the list, the installation and control of the printers would still be controlled by iPrint’s underlying authorization mechanisms.

We will discuss the all-in-one code approach a bit more in the next article, which will describe how to actually set printer lists up in your environment.

We are finally getting to the Fireworks Factory folks …