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

Tue Sep 26 14:18:45 UTC 2006

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

Added files:
	luci/test      : test_plan.html 

Log message:
	Genesis

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

/cvs/cluster/conga/luci/test/test_plan.html,v  -->  standard output
revision 1.1

--- conga/luci/test/test_plan.html
+++ -	2006-09-26 14:18:45.114732000 +0000
@@ -0,0 +1,27 @@
+<html>
+ <head><title>Conga Test Plan</title></head>
+ <body>
+  <h2>Conga Testing Plan</h2>
+  This document breaks the Conga remote administration tool down into 5 separate pieces for testing consideration:
+  <ul>
+   <li>The ricci agent</li>
+   <li>Luci Homebase Tab</li>
+   <li>Luci Cluster Tab</li>
+   <li>Luci Storage Tab</li>
+   <li>Installation/luci_admin app</li>
+  </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
+  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.
+  <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.
+  <h4>Luci Homebase Tab</h4>
+
+ </body>
+</html>


