[Cluster-devel] conga/luci/test test_plan.html

[jparsons@sourceware.org <jparsons@sourceware.org>]

CVSROOT:	/cvs/cluster
Module name:	conga
Changes by:	jparsons at sourceware.org	2006-09-26 14:57:44

Modified files:
	luci/test      : test_plan.html 

Log message:
	typos and a bit of content

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/test/test_plan.html.diff?cvsroot=cluster&r1=1.1&r2=1.2

--- conga/luci/test/test_plan.html	2006/09/26 14:18:44	1.1
+++ conga/luci/test/test_plan.html	2006/09/26 14:57:44	1.2
@@ -12,12 +12,13 @@
   </ul>
   For additional information about Conga and how it works, please see:<br/>
   sources.redhat.com/cluster/conga  for architectural info.<br/>
-  CVS checkout of conga/luci/docs/user_manual.html for a user manual
+  CVS checkout of conga/luci/docs/user_manual.html for a user manual<br/>
   sources.redhat.com/cluster/conga/usecases/usecase_index.html for use cases
   <h3>Ricci Agent Testing</h3>
-  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 rcci 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.<p/>
-  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. <br/>If a system with a ricci agent is rebooted, the ricci agent should come up again. If it does not, then there ios an error in the init script.
- <br/>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.
+  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.<p/>
+  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. <br/>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.
+ <br/>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.<br/>
+  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.
   <h3>Luci Testing</h3>
   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).<br/>
   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. <br/>Luci is organized into three tabs: Homebase, Cluster, and Storage. After logging in, you should be at the luci Homebase tab.