CSM GUI on Linux Strategy White Paper


Author: Bruce Potter, Document Version 1.5, 1/13/04

Introduction

Initially, the user interface for CSM on Linux was only a command line interface, with the exception of the DCEM GUI for dsh. There are many factors to consider in choosing the direction for GUIs for CSM on Linux. This white paper briefly discusses all those factors and gives the rationale for a strategy.

Requirements & Guiding Principles

Before developing a strategy, it is important to understand the requirements that should be satisfied. These are the perceived requirements for a GUI for CSM on Linux, based on customer interaction with CSM, WebSM, and Perspectives, and based other GUIs in the Linux environment.

Proposed Strategy

This section briefly describes a proposed direction for the GUI for CSM on Linux that tries to take into account all the requirements above and satisfy them as much as possible.

The proposal is to create a simple web browser interface to CSM using CGI, perl-mod, and perl scripts on the back end that produce HTML and Javascript to be displayed in a browser. A web browser interface is well suited for simple, straightforward interfaces (because it is hard to develop a slick, fancy browser interface). If kept simple, they load quickly, can be run from any machine and can perform acceptably over a phone line. The forms-like interface lends itself to task oriented interfaces, and the technology chosen is open and familiar to many Linux developers. There are also some smaller advantages to this approach. For example, any HTML editor can be used to lay out the interface, the help system can simply be done in HTML, and links can be placed throughout the interface and help pages to the many web resources we are creating for CSM (e.g. documents, FAQ, downloads, etc.). Also, this technology positions us to support PDAs in the future. If we correctly modularize the back-end code that is producing the HTML, a module can be written that produces HTML appropriate for display on a PDA.

(By the way, it is noteworthy that the next release of Microsoft's server version of Windows, .NET Enterprise Server, features a new browser-based interface for remote administration. It is the first thing that PC Magazine mentions in a recent review of a beta version of the OS.)

A version of this proposed interface is under development can be downloaded from http://rs6000.pok.ibm.com/afs/aix.kingston.ibm.com/project/csm/www/installCSM.html. Comments and suggestions for this interface are welcome and can be sent to the CSM mailing list.

We are currently building this web interface as a module within Webmin. Webmin is an open source, very lightweight, web-based, system management interface infrastructure and set of applications. It is well known in the Linux community and using it gives us the following advantages:

Why Not Use the WebSM CSM Interface on Linux?

This is a common (and valid) question so I will try to address it here. Although WebSM is a very full-featured GUI and the framework already runs on Linux (for the HMC), it does not satisfy several of the requirements listed above:

Despite these disadvantages, it still might make sense to provide the WebSM CSM interface on Linux under certain circumstances. For example, if a customer has both AIX and Linux CSM management servers, they may want to use the same GUI on both of them. Also, if the HMC becomes a CSM management server at some point, it would be appropriate to provide the same GUI for the HMC functions and the CSM functions. But even if WebSM is provided on Linux in these cases, it still makes sense to provide the proposed web interface on Linux as an alternative for customers to use, since it has a very different design point that may appeal to customers that might not tend to use WebSM.

Integration with Other IBM GUIs

Probably the hardest requirement to satisfy is to make the GUI work in some sensible way with the other related IBM system management GUIs. This is difficult because some of them don't work with each other and are based on very different technologies. Let's take them one at a time:

Integrated Solutions Console (ISC)

This is the strategic direction for system management GUIs for eServer.  ISC is a browser-based console framework based on JSP portlets.  The eServer strategy says that all future system management GUIs should be portlets that fit into this framework.  This gives a single console, with a consistent look, for many applications that our customers interact with.  So how does the strategy outlined in this paper mesh with the eServer strategy?  In the following ways:

Why Bother Developing a Lightweight Browser Interface for CSM on Linux?

With convergence with Director coming, ISC coming (see below), and the fact that many Linux administrators are satisfied with only a CLI, why bother developing a browser interface for CSM?  There are several reasons:

Top 10 Reasons to Use the CSM Web Interface...

13.  (OK, so we had more than 10...)  All your friends are using web interfaces for system administration and monitoring.

12.  The browser paradigm is familiar to you:  Forms, the Back button, bookmarks, online shopping, dating services....  You get the idea.

11.  You can run it from anywhere:  a Windows, Linux, or Mac desktop or notebook, from home over a phone line, DSL, or cable modem, the other side of the world, etc.

10.  It contains everything you need to know to do your administration tasks:  plain English explanations, hints & tips, links directly to relevant documentation, etc.

9.  It helps you learn the CSM commands.  In an organized interface, it shows you all the features that are available to you in CSM, and with the verbose preference turned on, it will show you all the CSM commands it is running.

8.  You can bookmark any page in the web interface, so you can later jump directly to that page.  And since you probably already have a web browser running, it starts up super fast.  This facilitates using the CSM command line interface for most common operations, and jumping to the web interface for complex or less frequently done operations.

7.  It has 2 full pages of diagnostic operations, hints, and links to assist you when things go wrong.

6.  All those confusing arguments for creating Conditions and Responses are explained and displayed in a simple form.

5.  You can monitor all the conditions in your cluster with a smooth, efficient, patent pending, web page update method.

4.  It automates the mysterious incantations necessary to filter out uninteresting entries from the AuditLog, so you don't accidentally list 20,000 entries.

3.  You can monitor the progress of multiple installations with progress bars and one line status fields, instead of bulky consoles.

2.  With the click of a button, you can monitor the performance of your nodes and see historical graphs of performance data.

1.  It is small (less than 200K !), fast, and open.  Since it is all perl code, you can see all the source, see how it does things, and contribute improvements to it.

Developing the Web Interface

Contributing to the development of this web interface is pretty straight-forward once you understand the basic approach that is being used:

Having the correct information about all these technologies is key.  Here are some references:

Conclusion

The proposed strategy and approach satisfies most of the requirements as we understand them.  Comments, opinions, and suggestions are welcome and can be sent to the CSM mailing list.