Conga Testing Plan
General Testing Notes
Most testing of Conga will undoubtedly be made through the luci user interface. This is the manner in which it is anticipated to be used. Scripts are available in the 'QA Goodies' repository detailed at the end of this document, that will test ricci directly and will be very valuable for identifying regressions and making certain upgrades go smoothly; Still, the large part of this document adddresses luci testing.
Every page throughout the luci interface has a title, which will be rendered in the title bar area of the browser. It is hoped that using these page names will promote immediate understanding of where an issue is taking place when qa and engineering communicate. It is also hoped that URLs will be pasted into BZ tickets whenever possible.
As a lead developer on Conga, I hope for a thorough QA shakeout of the product before release. I can tell you my greatest worry, and perhaps it might inform testing. I worry most about corner cases being missed in the code that results in errors that are not handles properly. If, at any time, a cryptic error message (such as 'Key error: missing "statusmessage" value', or 'Type Error: cannot concatenate string and none type') appears inn the browser window, then we have failed. The source of many of these types of error messages, I fear, will be attempts to contact ricci agents that are refusing connection for some reason. Please keep a lookout for these cases. Shutting down systems registered with luci and then poking and prodding them through the interface might be a good approach.
This document breaks the Conga remote administration tool down into 5 separate pieces for testing consideration:
- The ricci agent
- Luci Homebase Tab
- Luci Cluster Tab
- Luci Storage Tab
- Installation/luci_admin app
For additional information about Conga and how it works, please see:
sources.redhat.com/cluster/conga for architectural info.
sources.redhat.com/cluster/conga/doc/user_manual.html for a user manual
sources.redhat.com/cluster/conga/usecases/usecase_index.html for use cases
Ricci Agent Testing
The ricci agent is installed on every system to be remotely administered. It is a daemon that runs as non-root and talks to ricci modules via Dbus and Oddjob. The main ricci agent code acts as a dispatcher for the ricci modules, by reading the incoming XML and sending it via Dbus to the correct module, and then returning the modules result to the originating luci server.
The ricci agent also authenticates users via the root password of the system. Every effort has been made to make this process as secure as possible, such as scrambling memory allocated to the password string immediately after use, but it would still be worthwhile to test ricci's security by making it core dump during an authentication and seeing if the root password can be read in the core file.
If a system with a ricci agent is rebooted, the ricci agent should come up again. If it does not, then there is an error in the init script.
Ricci listens on port 11111. If a connection is made to port 11111, ricci responds that he is listening and available, and will also offer whether or not the system he is running on is part of a cluster. If so, the cluster name is provided. This capability is for cluster discovery. No other information about the system running is made available without authenticating to the ricci agent. If authentication is successful, the ricci agent will store the certificate/key information about the guest system. This information should persist, of course, between reboots.
It is possible to interact with a ricci agent without using a luci server. After authenticating with a luci server, the certificate used by the luci server could be used in a script that opens a connection to the ricci agent and writes XML to the connection. In practical use, this is not a security concern, as luci certs are in a directory which only root on the system hosting the luci server can read. It is, however, a potentially useful mechanism for script based regression testing of the ricci component. Documentation for the XML schema used by ricci is in CVS under conga/ricci/doc.
Luci Testing
After a luci server is installed, it is accessible via https connection to port 8084; but should be inaccessible immediately after install, until the initial admin password is set. The first time that the luci service is started, it checks to see if an admin password exists, and if it does not, it should offer the user (root user, as only root can start the luci service) the opportunity to set an initial admin password. The admin password can be changed at any time by running the luci_admin tool and restarting the luci service (more on the luci_admin tool later).
After the luci service is up and running and an admin password has been established, the next step is to log in. Browse to https://yourserver:8084/luci. You should see a log in page. After logging in, you will not need to log in again as long as a browser window remains open.
Luci is organized into three tabs: Homebase, Cluster, and Storage. After logging in, you should be at the luci Homebase tab.
Luci Homebase Tab
In a fresh luci install, there will be three options:
- Add a system
- Add an existing cluster
- Add a User
Testing the Add a System capability
This page is know as the 'luci - cluster - add system' page.
The 'Add a system to be managed' use case is satisfied here. The page allows for multiple systems to be added
Try and add systems that don't exist. Try usinng the wrong password on legitimate systems with ricci agents. See if you can add a system twice...once by hostname and once by IP address.