I apologize for the long wait between posts – it will not happen again with any of the series that I am planning for Cool Solutions. Trying to explain iManager pithily is a little tricky, and finishing this section got put on the back burner. As a reminder, although printer lists are useful by themselves I am using them to illustrate a method for extending Open Enterprise Server to serve your own organization’s needs.
In part one of this series we described a problem – the need to generate dynamic lists of iPrint printers – and the overall reasoning and outline of our solution. In part two we discussed how and why we would store our solution’s data in eDirectory. Now in part three we will discuss administration.
For a traditional service like TTP iPrint Printer lists there are two interfaces we will need to build: An end-user interface and an administrative interface. The former will be covered in a later article, and the latter is the subject of this one and the next.
Our end-user interface will be built with PHP, and it is tempting to custom-build the administrative interface with PHP as well. However, to do so would be to succumb to “Not Invented Here” Syndrome or its fellow-traveler CADT.
If we built our own custom administrative interface, then we are entirely responsible for it. Future updates to printer lists would require substantial work to update the administrative interface. Our administrators would have to learn yet another admin tool (like they have had to do with ZENworks and GroupWise) which might be inconsistent with mental model of OES. Most worryingly, we would have to audit the tool for security holes and generally make it as bug-free as possible because flaws in an admin tool can easily lead to exploits into our system with elevated privileges.
On the other hand, if we leverage a tool that already exists we retain consistency in the overall operation of the system (our piece works like everything else) and benefit from any underlying improvements to the admin frameworks.
There are good reasons to build our own admin tool, but in this particular case there are better reasons to extend an existing tool if possible … and the obvious tool to extend here is iManager: It comes with OES. It is web-based like our lists will be. It can already administer iPrint, our users, and eDirectory in general. Oh, and it has well-defined and supported methods for extension already.
(Pause to throw some shade in the direction of the OES DHCP/DNS Console and mourn the end of the iManager DNS and DHCP plug-ins.)
Alas, we do have to deal with the hatred a lot of sysadmins harbor for iManager.
Like a teenager with a mohawk and straight-As, iManager gets a bad rap but has a heart of gold. It is often criticized for being slow, buggy, or inelegant in its interface. This continues a proud tradition of sysadmins making these same complaints about whatever new administrative tool Novell developed all the way back to ConsoleOne and NWAdmin32.
The original idea behind iManager was that it would be a single administrative tool for all of Novell’s products that would not only be flexible enough to integrate with any enterprise product but also universally accessible across platforms via its web architecture. As an OES sysadmin I can affirm that it handles not only eDirectory-oriented administration well but that it is quite adept at complicated interactions such as NSS hardware administration, thus affirming the former goal. As a Mac user I am also very happy that it fulfills the latter.
Even though it is web-based, iManager is quite mature, having been released at least fifteen years ago (October 2001, with NetWare 6). That means that it was around before the XMLHttpRequest object that powers “Ajax” was widely implemented. Consequently iManager is not a “single page” application (outside of the Access Manager Dashboard) but belongs to a different era of web tools that rely on loading new pages in response to user interaction. I would argue that for an administrative tool this is a better model. The feedback from the page loads and form submissions gives an accurate representation of state. AJAX implementations with identical functionality can conceal communication issues between the client and server (both Vibe and Filr have such issues). Moreover, the simplicity of using POST, PUT, and GET makes tracking and interpreting the steps in an administrative workflow more coherent.
Despite its age iManager is still in active development. The modern administrative pages of Access Manager and Identity Manager are both built on top of iManager. They provide a good demonstration of how powerful it can be when a team takes it seriously and how well it fulfills its original design goals.
Nonetheless, there are aspects of iManager I dislike intensely. I have great reservations about Java and Tomcat applications, and iManager is based upon both (which makes the Ideas Portal request to “Replace iManager to work without Java” unintentionally hilarious – you may as well try to make cheese without milk). My reservations could (and might) fill an article by themselves. I also bemoan a lack of polish in some areas of iManager. For example, the image assets need updating to keep up with modern resolutions and the pages are not designed well for tablet form factors. Aggravatingly, when iManager encounters errors its default approach is to expose the underlying system error (which often has multiple possible causes) to the administrator rather than try more exception handling or attempt to guess what the cause might be based on application context.
The lack of polish comes in part because iManager is a necessity but it is not a revenue-generating product in its own right. Budgets are not lavished upon it to gild its HTML. That said, it would be a mistake to see these rough edges and assume that they sit on top of an unreliable, unsophisticated system. When you dig into iManager you discover just how well-planned it was in its role as one-stop administrative tool for a universe of diverse products.
Okay, you get the point that iManager is under-appreciated. So, how do we build an administrative interface for our printer lists with it?
Well, iManager happens to have a fully-supported, feature-rich, well-documented Developer Kit. Unfortunately it requires writing Java code (which I avoid if I can help it) and its capabilities are far too heavy for the simple administrative tasks we need to perform for iPrint printer lists. I highly recommend reading the link above to understand the range of possibilities one can marshall through iManager. Still, we are going to look at a lighter solution for our project.
Here we go: iManager Plug-in Studio, installed by default with iManager. and which is also documented in the NDK guide. Even better, “khurni” wrote a great tutorial in NetIQ Cool Solutions (soon to be part of Micro Focus Cool Solutions!) explaining how to use it.
There are only three administrative tasks we want to accomplish with printer lists: Create, Delete, and Modify. When we Delete a printer list, we delete it like any other eDirectory object and so we do not need a specialized iManager task for it. Instead we can use the standard “Delete Object” task under the “Directory Administration” role that is available in the iManager “Roles and Tasks” view.
That leaves us with “Create” and “Modify”, which we will make with Plug-in Studio. Except that is for the next article in this series.
Just like Martha Stewart, I have a plug-in already in the oven even as we prepare to mix the recipe. You can go ahead and download the plug-in here to install, and we will go over how it was created next time. None of the following instructions are required when creating the plug-in from scratch.
The file you downloaded is ttp_iprint_lists_imanager_plugins_v1.npm . To install it, log into iManager with an account with rights to administer iManager itself.
Import the file into iManager: Configure->Plugin Installation->Available Novell Plug-in Modules->Add
Choose the file “ttp_iprint_lists_imanager_plugins_v1.npm and click “Okay”
After importing the plug-in, restart Novell Tomcat (for iManager) using “rcnovell-tomcat6 restart” from the server console or an SSH session. This will ensure that iManager has loaded it.
Once the plug-in has imported, we are not finished. Some effort is required to make iManager happy with the arrangement. We will need to create a Module, Role, and Property Book for the plug-in to be assigned to. What follows is a quick version – the next article will describe these steps with greater granularity.
Go to “Role Based Services->RBS Configuration” and pick the collection you would like to include the printer lists administration. Create a new iManager Module with name “TTP iPrint Lists”
Then create a new Role With Name “TTP Printer List", Assigned Task: “TTP iPrint Assign, and Category: “Printing”
After all of this, restart Novell Tomcat again.
Return to the Role Collection where the Module and Role were created. Create a new property book with Name: “Manage TTP iPrint Printer Lists"
Assign object type “ttpiPrintPrinterList
Assign the Other page and any pages obviously corresponding to the printer lists.
Assign to role TTP Printer List
The plug-in is now fully configured on this server and will show up as “TTP Printer List” under the “Roles and Tasks” view in iManager. Under this category are links for “Manage TTP iPrint Printer Lists” and “TTP iPrint List Create”.
Once you have installed the plugins in one instance of iManager, see TID 3447396 for instructions to install on other instances in the same tree. If these instructions do not work, just copy the files in the /var/opt/novell/iManager/nps/portal/modules/custom directory from one server to another and restart iManager.
“TTP Printer List” menu under iManager’s Roles and Tasks view can create printer lists and manage which members and printers belong to them.
Under the “TTP iPrint List Create” task we have very few options. We can set the CN, context, Title, and Description. The first two are required of any eDirectory object, and you will naturally be familiar with them. Title might be the most important field here as it will be the friendly name that identifies the printer list to our end users. Description is optional but highly recommended as a guide for users to understand which printer they are looking at.
To actually make the printer lists useful, we must go to the “Manage TTP iPrint Printer Lists” link. There we can modify Title and Description. More importantly, we can add iPrint printer objects to our list (which is the entire point of having printer lists). Finally, we can modify the set of “members” of the printer list. These members are objects in the tree that should be able to see the printer lists on-demand as a convenience (i.e. membership is not about rights but about organization). A member of a printer list object should be a user, group, or OU.
Once again, to delete a printer list, use the “Delete Object” task under “Directory Administration” within the Roles and Tasks view.
Part Four of this series will be posted shortly and describes the step-by-step instructions for creating the iManager plug-in from scratch.
Part Five will introduce the technologies used to actually display printer lists to our end users.